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Abstract 


This  paper  makes  three  contributions.  First,  we  present  a  proof  technique  that  offers 
system  designers  the  aame  ease  pf  reasoning  about  nested  transaction  systems  as  is  given  by 
the  classical  theory  for  systems/without  nesting,  and  yet  can  be  used  to  verify  that  a  system 
satisfies  the  robust  1  user  view  definition  of  correctness  of Second,  as  applications  of 
the  technique,  we  verify  the  correctness  of  Moss’  read/write  locking  algorithm  for  nested 
transactions,  and  of  an  undo  logging  algorithm  that  has  not  previously  been  presented  or 
proved  for  nested  transaction  systems.  Third,  we  make  explicit  the  assumptions  used  for 
this  proof  technique,  assumptions  that  are  usually  made  implicitly  in  the  classical  theory, 
and  therefore  we  clarify  the  type  of  system  for  which  the  classical  theory  itself  can  reliably 
be  used.j^ 


'  Keywords:  concurrency  control,  recovery,  fault-tolerance,  nested  transactions,  serializ- 
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1  Introduction 

The  notion  of  “atomic  transaction”  was  originally  developed  to  hide  the  effects  of  failures  and 
concurrency  in  centralized  database  systems.  Recently,  a  generalization  to  “nested  transac¬ 
tions”  has  been  advocated  as  a  way  of  organizing  distributed  systems  in  which  information  is 
maintained  in  persistent  modifiable  objects.  Nested  transactions  allow  the  benefits  of  atomicity 
to  be  used  within  a  transaction,  so  that,  for  example,  a  transaction  can  include  several  simul¬ 
taneous  remote  procedure  calls,  which  can  be  coded  without  considering  possible  interference 
among  them.  Examples  of  systems  using  nested  transactions  are  Argus  [9]  and  Camelot  [15].  In 

‘Supported  in  part  by  the  Defense  Advanced  Research  Projects  Agency  (DARPA)  under  Contract  N00014- 
83-K-0125. 

Supported  in  part  by  the  National  Science  Foundation  under  Grant  CCR-86-11442,  in  part  by  the  Defense 
Advanced  Research  Projects  Agency  (DARPA)  under  Contract  N00014-89-J-1988,  and  in  part  by  the  Office  of 
Naval  Research  under  Contract  N00014-85-0168. 

'Supported  in  part  by  the  National  Science  Foundation  under  Grant  CCR-8716884,  and  in  part  by  the  Defense 
Advanced  Research  Projects  Agency  (DARPA)  under  Contract  N00014-89-J-1988. 


these  systems  “atomic”  objects  can  be  created  and  operations  on  these  objects  are  guaranteed 
to  be  serializable,  even  though  they  execute  concurrently.  In  both  Argus  and  Camelot  the  de¬ 
fault  algorithm  used  for  concurrency  control  and  recovery  is  the  locking  protocol  of  Moss  [13], 
but  the  implementor  of  an  object  has  the  option  of  writing  his  or  her  own  concurrency  control 
and  recovery  routines. 

A  natural  question  is  what  “correctness”  means  for  concurrency  control  and  recovery  algo¬ 
rithms  in  a  nested  transaction  system.  Once  a  specification  for  correct  functioning  has  been 
given,  one  seeks  to  prove  that  existing  algorithms  are  correct.  Moreover,  the  possibility  of 
user-defined  concurrency  control  in  a  system  leads  one  to  seek  proof  methods  that  are  modular, 
so  that  when  one  object  is  reimplemented  (for  performance  reasons)  in  a  previously  correct 
system,  the  new  system  may  be  proved  correct  without  needing  to  reconsider  those  parts  that 
have  not  changed.  Such  specification  and  proof  issues  have  been  addressed  in  a  major  research 
project  started  by  Lynch  and  Merritt  [10]  and  continued  in  [5,  6,  8,  4,  1,  11]. 

In  [10],  a  notion  of  correctness  called  “serial  correctness”  is  defined  for  nested  transaction 
systems.  The  definition  of  “serial  correctness”  presented  there  is  a  “user  view”  specification:  the 
users  of  the  transaction  system  should  only  be  able  to  observe  behavior  that  they  could  observe 
when  interacting  with  a  system  in  which  their  transactions  were  run  without  concurrency  and 
without  failure  after  partial  activity.  The  definition  of  serial  correctness  embodies  not  only  the 
serializability  condition  of  the  classical  theory,  but  also  the  “external  consistency”  condition, 
i.e.,  that  the  apparent  serial  execution  must  not  reverse  the  order  of  any  pair  of  transactions 
for  which  one  completed  before  the  other  was  invoked.  Also,  unlike  the  classical  theory,  this 
definition  of  serial  correctness  is  explicitly  formulated  to  apply  to  systems  in  which  transactions 
can  abort;  in  the  classical  theory,  aborts  are  handled  by  considering  only  executions  in  which 
all  transactions  commit.1 

The  definition  of  serial  correctness  from  [10]  is  used  in  [10,  5],  where  a  proof  technique 
is  developed  for  verifying  Moss’  algorithm.  Modular  proof  techniques  for  locking  algorithms 
can  be  found  in  [4],  The  same  definition  and  proof  techniques  have  been  used  in  proofs  of 
the  correctness  of  several  other  kinds  of  transaction-processing  algorithms,  including  multi¬ 
version  timestamp-based  algorithms  for  concurrency  control  and  recovery  [1],  algorithms  for 
management  of  replicated  data  [6],  and  algorithms  for  management  of  orphan  transactions  [8]. 
The  proof  techniques  of  these  papers  are  very  general.  They  apply  to  large  classes  of  systems, 
including  those  where  different  data  objects  are  implemented  independently,  and  where  the 
type  of  the  objects  can  be  used  to  obtain  increased  concurrency  (as  in  [17]).  We  summarize  the 
system  model,  definition  of  serial  correctness,  and  main  proof  technique  in  the  next  section. 

We  can  contrast  the  development  of  our  theory  of  serial  correctness  for  nested  transaction 
systems  with  the  classical  serializability  theory  for  systems  without  transaction  nesting,  as  pre¬ 
sented  (for  example)  in  [14]  and  [3].  The  classical  theory  uses  a  system  model  and  correctness 
definition  that  are  somewhat  more  restrictive  than  necessary;  for  example,  the  classical  correct¬ 
ness  definition  is  not  stated  in  terms  of  the  user  view  of  the  system,  but  rather  in  terms  of  the 
activity  at  the  data  objects.  The  classical  mode!  and  definition  work  very  well  for  a  number 
of  simple  update-in- place  algorithms,  but  a  different  definition  of  correctness  is  needed  to  cope 
with  multiversion  algorithms,  and  yet  another  for  re.  ’i  lion  management.  The  classical  theory 
is  also  restricted  in  that  it  deals  almost  exclusively  \i  :  data  objects  allowing  only  read  and 
write  operations. 

1  As  discussed  in  [16],  aborts  must  be  modeled  explicitly  to  analyze  the  subtle  interactions  between  concurrency 
control  and  recovery.  Because  it  does  not  model  aborts  explicitly,  and  implicitly  assumes  an  “update-in-place” 
model  for  recovery,  the  classical  theory  is  not  general  enough  to  model  certain  kinds  of  algorithms. 
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An  advantage  of  the  classical  theory,  however,  is  that  for  the  simplest  concurrency  control 
algorithms  such  as  two-phase  locking  or  single  version  timestamps,  it  yields  extremely  simple 
and  intuition-supporting  proofs.  These  proofs  are  based  on  the  absence  of  cycles  in  a  “seri¬ 
alization  graph,”  a  graph  whose  nodes  are  the  transactions  and  whose  edges  record  conflicts 
between  activity  of  the  transactions. 

We  would  like  to  be  able  to  combine  the  best  features  of  both  theories.  In  particular, 
we  would  like  to  be  able  to  use  serialization  graph  proof  techniques  similar  to  those  of  the 
classical  theory  to  reason  about  nested  transaction  systems,  wherever  this  is  possible.  We 
would  especially  like  to  use  such  techniques  to  prove  that  such  systems  satisfy  the  user  view 
serial  correctness  condition  of  [10].  We  would  also  like  to  extend  the  applicability  of  serialization 
graph  techniques  to  data  objects  that  admit  other  kinds  of  operations  besides  reads  and  writes. 
In  this  paper,  we  show  how  to  combine  the  two  theories  in  these  ways. 

More  specifically,  we  develop  a  proof  technique  for  nested  transaction  systems  in  which 
proofs  have  the  same  simple  form  as  in  the  classical  theory,  namely,  one  must  show  that  a  graph 
(having  transactions  for  nodes,  and  edges  representing  necessary  ordering  between  transactions) 
is  acyclic.  Thus,  we  define  a  new  kind  of  “serialization  graph”  and  prove  that,  under  certain 
assumptions,  the  absence  of  cycles  in  this  graph  is  a  sufficient  condition  to  ensure  the  serial 
correctness  of  a  system.  In  the  first  part  of  the  paper,  we  restrict  our  attention  to  systems  in 
which  each  data  object  admits  only  read  and  write  operations.  For  such  systems,  we  assume 
that  (once  aborted  transactions’  activity  is  ignored)  a  read  operation  always  returns  the  value 
written  by  the  most  recent  write  operation.  This  assumption  is  true  of  systems  in  which  each 
data  object  is  stored  in  a  single  location  that  is  overwritten  by  any  write  access,  and  where  an 
underlying  recovery  system  restores  the  appropriate  old  value  when  an  ancestor  of  the  most 
recent  write  is  aborted. 


In  much  of  the  classical  work  on  database  concurrency  control,  these  restrictions  and  as¬ 
sumptions  are  made  early  on,  and  in  fact  the  definition  of  correctness  often  includes  them. 
Systems  satisfying  these  assumptions  are  very  common,  and  while  we  feel  that  it  is  inappro¬ 
priate  to  make  these  assumptions  when  defining  the  correctness  condition  to  be  satisfied,  it  is 
clearly  useful  to  find  a  simple  sufficient  condition  that  guarantees  correctness  when  the  system 
does  satisfy  them. 

We  note  that  in  contrast  to  the  classical  theory,  the  acyclicity  of  the  graphs  we  construct 
is  merely  a  sufficient  condition  for  serial  correctness,  rather  than  necessary  and  sufficient.  This 
is  primarily  because  our  notion  of  serial  correctness,  based  as  it  is  on  the  user’s  view  of  the 
system,  is  not  as  restrictive  as  the  one  used  in  the  classical  theory. 

After  presenting  our  results  for  reads  and  writes,  we  indicate  how  they  can  be  generalized 
to  arbitrary  data  types.  That  is,  we  define  serialization  graphs  for  systems  with  objects  of 
arbitrary  data  type,  and  prove  once  again  that  absence  of  cycles  implies  serializability.  Once 
again,  the  values  returned  by  accesses  to  objects  are  assumed  to  satisfy  special  restrictions. 

We  use  our  serialization  graphs  to  prove  correctness  of  two  algorithms — the  read/write  lock-  __ 

ing  algorithm  of  Moss  and  an  undo  logging  algorithm.  (The  latter  algorithm  is  a  generalization  _ _ 

to  nested  transaction  systems  of  an  algorithm  due  to  Weihl  [16]).  I 

Other  work  has  also  been  done  on  modeling  nested  transaction  systems.  Iladzilacos  and  I 
Iladzilacos  [7]  present  a  generalization  of  the  classical  theory  to  handle  “object  bases,”  which  ^ 
exhibit  a  nesting  structure  very  much  like  that  considered  in  this  paper.  (Our  objects  corre-  3ZZ 
spond  to  the  instance  variables  in  their  objects,  and  our  accesses  to  objects  correspond  to  the 
local  steps  that  access  the  instance  variables.)  They  define  a  serialization  graph  construction, 
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and  give  an  acyclicity  condition  for  serializability.  However,  they  do  not  consider  recovery2,  and 
their  basic  model  is  significantly  less  general  than  ours  (for  example,  their  correctness  condi¬ 
tion  is  appropriate  only  with  an  update-in-place  single- version  implementation  of  objects,  while 
we  permit  multi-version  implementations).  Beeri,  Bernstein  and  Goodman  [2]  present  proof 
techniques  that  are  useful  for  systems  organized  using  multiple  levels  of  abstraction,  with  con¬ 
currency  control  performed  separately  at  each  level.  The  nesting  in  such  systems  corresponds 
to  levels  of  data  abstraction,  while  the  nesting  considered  here  corresponds  more  to  levels  of 
procedural  abstraction.  It  may  be  that  the  techniques  in  [2]  could  be  applied  to  the  kinds 
of  systems  we  consider  here,  but  their  techniques  are  more  complicated,  allowing  replacement 
of  entire  subtrees  of  nested  activity  by  single  actions  as  well  as  the  reordering  of  actions  in  a 
history.  Also,  they  do  not  present  a  simple  acyclic  graph  condition  for  correctness,  and  they  do 
not  model  recovery  in  their  work. 

The  remainder  of  this  paper  is  organized  as  follows.  First,  in  Section  2,  we  summarize  our 
earlier  work  on  which  this  work  is  based.  Then,  in  Section  3,  we  give  the  assumptions  we  make 
for  systems  based  on  read/write  objects;  that  is,  we  define  such  systems  and  define  the  condition 
that  says  that  all  reads  return  the  latest  value.  In  Section  4,  we  present  our  serialization  graph 
construction  and  the  theorem  that  says  that  acyclicity  of  the  serialization  graph  implies  serial 
correctness.  In  Section  5,  we  give  a  proof  of  Moss’  algorithm  using  our  serialization  graphs.  In 
Section  6,  we  indicate  how  to  extend  the  work  to  other  data  types  besides  read/write  objects; 
this  section  includes  a  description  and  proof  of  the  general  undo  logging  algorithm.  Finally,  we 
conclude  with  a  discussion  and  some  suggestions  for  further  work. 

2  Background 

In  this  section,  we  summarize  the  main  concepts  from  our  earlier  work  that  are  used  in  the  rest 
of  the  paper.  Complete  details  can  be  found  in  [11].  The  reader  who  is  already  familiar  with 
our  work,  or  who  is  not  interested  in  the  details  of  the  proofs,  may  skip  or  skim  this  section. 

2.1  Review:  The  Input/Output  Automaton  Model 

The  following  is  a  brief  introduction  to  the  formal  model  that  we  use  to  describe  and  reason 
about  systems.  This  model  is  treated  in  detail  in  [12]  and  [11]. 

All  components  in  our  systems,  transactions,  objects  and  schedulers,  will  be  modelled  by 
I/O  automata.  An  I/O  automaton  A  has  a  set  of  states,  some  of  which  are  designated  as  initial 
states.  It  has  actions ,  divided  into  input  actions,  output  actions  and  internal  actions.  We  refer 
to  both  input  and  output  actions  as  external  actions.  We  use  the  terms  in{A),  out(A),  and 
ext(A)  to  refer  to  the  sets  of  input  actions,  output  actions  and  external  actions  of  the  automaton 
A.  An  automaton  has  a  transition  relation,  which  is  a  set  of  triples  of  the  form  (s',  7r,  s),  where 
s'  and  s  are  states,  and  7r  is  an  action.  This  triple  means  that  in  state  s',  the  automaton  can 
atomically  do  action  k  and  change  to  state  s.  An  element  of  the  transition  relation  is  called  a 
step  of  the  automaton.3 

The  input  actions  model  actions  that  arc  triggered  by  the  environment  of  the  automaton, 
while  the  output  actions  model  the  actions  that  are  triggered  by  the  automaton  itself  and  are 
potentially  observable  by  the  environment,  and  internal  actions  model  changes  of  stale  that  are 
not  directly  detected  by  the  environment. 

2A  later  manuscript  of  their  paper  has  extended  the  results  to  include  recovery. 

3  Also,  an  I/O  automaton  has  an  equivalence  relation  on  the  set  of  ouipul  and  internal  actions.  This  is  needed 
only  to  discuss  fairness  and  will  not  be  mentioned  further  in  this  paper. 
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Given  a  state  s'  and  an  action  it,  we  say  that  n  is  enabled  in  s'  if  there  is  a  state  s  for  which 
(a',5r,s)  is  a  step.  We  require  that  each  input  action  t  be  enabled  in  each  state  s',  i.e.,  that  an 
I/O  automaton  must  be  prepared  to  receive  any  input  action  at  any  time. 

A  finite  execution  fragment  of  A  is  a  finite  alternating  sequence  sottiSi^  . .  .  7rn.sn  of  states 
and  actions  of  A,  ending  with  a  state,  such  that  each  triple  (s',  7r,  s)  that  occurs  as  a  consecutive 
subsequence  is  a  step  of  A.  We  also  say  in  this  case  that  (so,tti  . .  .irn,sn)  is  an  extended  step 
of  A,  and  that  ( so,/3,sn )  is  a  move  of  A  where  /3  is  the  subsequence  of  . .  .nn  consisting  of 
external  actions  of  A.  A  finite  execution  is  a  finite  execution  fragment  that  begins  with  a  start 
state  of  A. 

From  any  execution,  we  can  extract  the  schedule,  which  is  the  subsequence  of  the  execution 
consisting  of  actions  only.  Because  transitions  to  different  states  may  have  the  same  actions, 
different  executions  may  have  the  same  schedule.  From  any  execution  or  schedule,  we  can 
extract  the  behavior,  which  is  the  subsequence  consisting  of  the  external  actions  of  A.  We  write 
finbehs(A)  for  the  set  of  all  behaviors  of  finite  executions  of  A. 

We  say  that  a  finite  schedule  or  behavior  f3  can  leave  A  in  state  s  if  there  is  some  execution 
with  schedule  or  behavior  a  and  final  state  s.  We  say  that  an  action  n  is  enabled  after  a  schedule 
or  behavior  a,  if  there  exists  a  state  s  such  that  n  is  enabled  in  s  and  a  can  leave  A  in  state  s. 

Since  the  same  action  may  occur  several  times  in  an  execution,  schedule  or  behavior,  we 
refer  to  a  single  occurrence  of  an  action  as  an  event. 

We  describe  systems  as  consisting  of  interacting  components,  each  of  which  is  an  I/O  au¬ 
tomaton.  It  is  convenient  and  natural  to  view  systems  as  I/O  automata,  also.  Thus,  we  define 
a  composition  operation  for  I/O  automata,  to  yield  a  new  I/O  automaton.  A  collection  of  I/O 
automata  is  said  to  be  strongly  compatible  if  any  internal  action  of  any  one  automaton  is  not 
an  action  of  any  other  automaton  in  the  collection,  any  output  action  of  one  is  not  an  output 
action  of  any  other,  and  no  action  is  shared  by  infinitely  many  automata  in  the  collection.  A 
collection  of  strongly  compatible  automata  may  be  composed  to  create  a  system  S. 

A  state  of  the  composed  automaton  is  a  tuple  of  states,  one  for  each  component  automaton, 
and  the  start  states  are  tuples  consisting  of  start  states  of  the  components.  An  action  of  the 
composed  automaton  is  an  action  of  a  subset  of  the  component  automata.  It  is  an  output  of 
the  system  if  it  is  an  output  for  any  component.  It  is  an  internal  action  of  the  system  if  it  is  an 
internal  action  of  any  component.  During  an  action  7r  of  S,  each  of  the  components  that  has 
action  7r  carries  out  the  action,  while  the  remainder  stay  in  the  same  state.  If  (3  is  a  sequence  of 
actions  of  a  system  with  component  A,  then  we  denote  by  f3\  A  the  subsequence  of  j3  containing 
all  the  actions  of  A.  Clearly,  if  (5  is  a  finite  behavior  of  the  system  then  (3\A  is  a  finite  behavior 
of  A. 

Let  A  and  B  be  automata  with  the  same  external  actions.  Then  A  is  said  to  implement  B 
if  finbehs(A)  C  finbehs(B).  One  way  in  which  this  notion  can  be  used  is  the  following.  Suppose 
we  can  show  that  an  automaton  A  is  “correct,”  in  the  sense  that  its  finite  behaviors  all  satisfy 
some  specified  property.  Then  if  another  automaton  B  implements  A,  B  is  also  correct. 

2.2  Review:  Serial  Systems  and  Correctness 

In  this  section  of  the  paper  we  summarize  the  definitions  for  serial  systems,  which  consist 
of  transaction  automata  and  serial  object  automata  communicating  with  a  serial  scheduler 
automaton.  More  details  can  be  found  in  [11]. 

Transaction  automata  represent  code  written  by  application  programmers  in  a  suitable  pro¬ 
gramming  language.  Serial  object  automata  serve  as  specifications  for  permissible  behavior  of 
data  objects.  They  describe  the  responses  the  objects  should  make  to  arbitrary  sequences  of  op- 
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oration  invocations,  assuming  that  later  invocations  wait  for  responses  to  previous  invocations. 
The  serial  scheduler  handles  the  communication  among  the  transactions  and  serial  objects,  and 
thereby  controls  the  order  in  which  the  transactions  can  take  steps.  It  ensures  that  no  two  sib¬ 
ling  transactions  are  active  concurrently — that  is,  it  runs  each  set  of  sibling  transactions  serially. 
The  serial  scheduler  is  also  responsible  for  deciding  if  a  transaction  commits  or  aborts.  The 
serial  scheduler  can  permit  a  transaction  to  abort  only  if  its  parent  has  requested  its  creation, 
but  it  has  not  actually  been  created.  Thus,  in  a  serial  system,  all  sets  of  sibling  transactions 
are  run  serially,  and  in  such  a  way  that  no  aborted  transaction  ever  performs  any  steps. 

A  serial  system  would  not  be  an  interesting  transaction-processing  system  to  implement. 
It  allows  no  concurrency  among  sibling  transactions,  and  has  only  a  very  limited  ability  to 
cope  with  transaction  failures.  However,  we  are  not  proposing  serial  systems  as  interesting 
implementations;  rather,  we  use  them  exclusively  as  specifications  for  correct  behavior  of  other, 
more  interesting  systems. 

We  represent  the  pattern  of  transaction  nesting,  a  system  type ,  by  a  set  r  of  transaction 
names,  organized  into  a  tree  by  the  mapping  parent,  with  To  as  the  root.  In  referring  to  this 
tree,  we  use  traditional  terminology,  such  as  child,  leaf,  ancestor,  lea  (that  is,  least  common 
ancestor),  and  descendant.  (A  transaction  is  its  own  ancestor  and  descendant.)  The  leaves  of 
this  tree  are  called  accesses.  The  accesses  are  partitioned  so  that  each  element  of  the  partition 
contains  the  accesses  to  a  particular  object.  In  addition,  the  system  type  specifies  a  set  of  return 
values  for  transactions  (henceforth  simply  called  values).  If  T  is  a  transaction  name  that  is  an 
access  to  the  object  name  X  and  v  is  a  value,  we  say  that  the  pair  ( T ,  v)  is  an  operation  of  X. 

The  tree  structure  can  be  thought  of  as  a  predefined  naming  scheme  for  all  possible  trans¬ 
actions  that  might  ever  be  invoked.  In  any  particular  execution,  however,  only  some  of  these 
transactions  will  actually  take  steps.  We  imagine  that  the  tree  structure  is  known  in  advance 
by  all  components  of  a  system.  The  tree  will,  in  general,  be  infinite  and  have  infinite  branching. 

The  classical  transactions  of  concurrency  control  theory  (without  nesting)  appear  in  our 
model  as  the  children  of  a  “mythical”  transaction,  To,  the  root  of  the  transaction  tree.  Trans¬ 
action  To  models  the  environment  in  which  the  rest  of  the  transaction  system  runs.  It  has 
actions  that  describe  the  invocation  and  return  of  the  classical  transactions.  It  is  often  natural 
to  reason  about  To  in  the  same  way  as  about  all  of  the  other  transactions.  The  only  transactions 
that  actually  access  data  are  the  leaves  of  the  transaction  tree,  and  thus  they  are  distinguished 
as  “accesses.”  (Note  that  leaves  may  exist  at  any  level  of  the  tree  below  the  root.)  The  internal 
nodes  of  the  tree  model  transactions  whose  function  is  to  create  and  manage  subtransactions, 
but  not  to  access  data  directly. 

A  serial  system  of  a  given  system  type  is  the  composition  of  a  set  of  I/O  automata.  This 
set  contains  a  transaction  automaton  for  each  non-access  node  of  the  transaction  tree,  a  serial 
object  automaton  for  each  object  name,  and  a  serial  scheduler.  These  automata  are  described 
below. 


2.2.1  Transactions 

A  non-access  transaction  T  is  modelled  as  a  transaction  automaton  Ap,  an  I/O  automaton  with 
the  following  external  actions.  (In  addition,  Ap  may  have  arbitrary  internal  actions.) 

Input: 

CREATE(T) 

REPORT_COMMIT(T',u),  for  T'  a  child  of  T,  v  a  value 
Output: 
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REQUEST.CREATE(T'),  for  V  a  child  of  T 
REQUEST_C0MMIT(7  >),  for  v  a  value 


The  CREATE  input  action  “wakes  up”  the  transaction.  The  REQUEST_CREATE  output 
action  is  a  request  by  T  to  create  a  particular  child  transaction.  The  REPORT-COMMIT 
input  action  reports  to  T  the  successful  completion  of  one  of  its  children,  and  returns  a  value 
recording  the  results  of  that  child’s  execution.  The  REPORT-ABORT  input  action  reports  to 
T  the  unsuccessful  completion  of  one  of  its  children,  without  returning  any  other  information. 
The  REQUEST-COMMIT  action  is  an  announcement  by  T  that  it  has  finished  its  work,  and 
includes  a  value  recording  the  results  of  that  work. 

We  leave  the  executions  of  particular  transaction  automata  largely  unconstrained;  the  choice 
of  which  children  to  create  and  what  value  to  return  will  depend  on  the  particular  implemen¬ 
tation.  For  the  purposes  of  the  systems  studied  here,  the  transactions  are  “black  boxes.” 
Nevertheless,  it  is  convenient  to  assume  that  behaviors  of  transaction  automata  obey  certain 
syntactic  constraints,  for  example  that  they  do  not  request  the  creation  of  children  before  they 
have  been  created  themselves  and  that  they  do  not  request  to  commit  before  receiving  reports 
about  all  the  children  whose  creation  they  requested.  We  therefore  require  that  aL'  transaction 
automata  preserve  transaction  well-formedness ,  as  defined  formally  in  [11]. 

2.2.2  Serial  Objects 

Recall  that  transaction  automata  are  associated  with  non-access  transactions  only,  and  that 
access  transactions  model  abstract  operations  on  shared  data  objects.  We  associate  a  single  I/O 
automaton  with  each  object  name.  The  external  actions  for  each  object  are  just  the  CREATE 
and  REQUEST-COMMIT  actions  for  all  the  corresponding  access  transactions.  Although  we 
give  these  actions  the  same  kinds  of  names  as  the  actions  of  non-access  transactions,  it  is  helpful 
to  think  of  the  actions  of  access  transactions  in  other  terms  also:  a  CREATE  corresponds  to 
an  invocation  of  an  operation  on  the  object,  while  a  REQUEST-COMMIT  corresponds  to  a 
response  by  the  object  to  an  invocation.  Thus,  we  model  the  serial  specification  of  an  object  X 
(describing  its  activity  in  the  absence  of  concurrency  and  failures)  by  a  serial  object  automaton 
Sx  with  the  following  external  actions.  (In  addition,  Sx  may  have  arbitrary  internal  actions.) 

Input: 

CREATE(T),  for  T  an  access  to  X 
Output: 

REQUEST_COMMIT(T,u),  for  T  an  access  to  X , 

v  a  value 

As  with  transactions,  while  specific  objects  are  left  largely  unconstrained,  it  is  convenient 
to  require  that  behaviors  of  serial  objects  satisfy  certain  syntactic  conditions.  Let  a  be  a 
sequence  of  external  actions  of  Sx-  We  say  that  a  is  serial  object  well-formed  for  X  if  it  is 
a  prefix  of  a  sequence  of  the  form  CREATE(r1)REQUEST-COMMIT(Ti,t;i)CREATE(T2)RE- 
QUEST_C0MMIT(72,U2)-  where  T{  ^  Tj  when  i  ^  j.  We  require  that  every  serial  object 
automaton  preserve  serial  object  well-formedness.4 

*This  is  formally  defined  in  [11]  and  means  that  the  object  does  not  violate  well-formedness  unless  its  envi¬ 
ronment.  has  done  so  first. 
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2.2.3  Serial  Scheduler 


The  third  kind  of  component  in  a  serial  system  is  the  serial  scheduler.  The  transactions  anti 
serial  objects  have  been  specified  to  be  any  1/0  automata  whose  actions  and  behavior  satisfy 
simple  restrictions.  The  serial  scheduler,  however,  is  a  fully  specified  automaton,  particular  to 
each  system  type.  It  runs  transactions  according  to  a  depth- first  traversal  of  the  transaction 
tree.  The  serial  scheduler  can  choose  nondeterministically  to  abort  any  transaction  whose 
parent  has  requested  its  creation,  as  long  as  the  transaction  has  not  actually  been  created. 
Each  child  of  T  whose  creation  is  requested  must  be  either  aborted  or  run  to  commitment  with 
no  siblings  overlapping  its  execution,  before  T  can  commit.  The  result  of  a  transaction  can  be 
reported  to  its  parent  at  any  time  after  the  commit  or  abort  has  occurred. 

The  actions  of  the  serial  scheduler  are  as  follows. 

Input: 

REQUEST.CREATE (T),  for  T  ±  T0 
REQUEST_COMMIT(T,u),  for  T  a  transaction  name, 

v  a  value 

Output: 

CREATE(T),  for  T  a  transaction  name 
COMMIT (T),  for  T  ±  T0 
ABORT (T),  for  T±T0 

REP0RT_C0MMIT(7»,  for  T  ^  T0,  v  a  value 
REP0RT_AB0RT(T),  for  T  ±  T0 

The  REQUEST.CREATE  and  REQUEST-COMMIT  inputs  are  intended  to  be  identified 
with  the  corresponding  outputs  of  transaction  and  serial  object  automata,  and  correspondingly 
for  the  CREATE,  REPORT-COMMIT  and  REPORT-ABORT  output  actions.  The  COMMIT 
and  ABORT  output  actions  mark  the  point  in  time  where  the  decision  on  the  fate  of  the 
transaction  is  irrevocable. 

The  details  of  the  states  and  transition  relation  for  the  serial  scheduler  can  be  found  in  [11]. 
2.2.4  Serial  Systems  and  Serial  Behaviors 

A  aerial  system  is  the  composition  of  a  strongly  compatible  set  of  automata  consisting  of  a 
transaction  automaton  Aj  for  each  non-access  transaction  name  T,  a  serial  object  automaton 
Sx  for  each  object  name  X ,  and  the  serial  scheduler  automaton  for  the  given  system  type. 

The  discussion  in  the  remainder  of  this  paper  assumes  an  arbitrary  but  fixed  system  type 
and  serial  system,  with  Aj-  as  the  non-access  transaction  automata,  and  Sx  as  the  serial  object 
automata.  We  use  the  term  serial  behaviors  for  the  system’s  behaviors.  We  give  the  name  serial 
actions  to  the  external  actions  of  the  serial  system.  The  COMMIT(T)  and  ABORT(T)  actions 
are  called  completion  actions  for  T. 

We  introduce  some  notation  that  will  be  useful  later.  Let  T  be  any  transaction  name.  If  7r  is 
one  of  the  serial  actions  CREATE(T),  REQUEST-CREATE(T'),  REPORT_COMMIT(r,t/), 
REPORT-ABORT(T'),  or  REQUEST_COMMIT(T,i;),  where  T'  is  a  child  of  T,  then  we  define 
transaction^ 7r)  to  be  T.  If  x  is  any  serial  action,  then  we  define  hightransaction(x)  to  be 
transaction^)  if  x  is  not  a  completion  action,  and  to  be  T,  if  x  is  a  completion  action  for  a 
child  of  T.  Also,  if  x  is  any  serial  action,  we  define  lowtransaction( x)  to  be  transaction(x)  if  x 
is  not  a  completion  action,  and  to  be  T,  if  x  is  a  completion  action  for  T.  If  x  is  a  serial  action 
of  the  form  CREATE(T’)  or  REQUEST-COMMIT^,?’),  where  T  is  an  access  to  A”,  then  we 
define  object(x)  to  be  A. 
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If  f3  is  a  sequence5  of  actions,  T  a  transaction  name  and  X  an  object  name,  we  define  (3\ T 
to  be  the  subsequence  of  /?  consisting  of  those  serial  actions  tt  such  that  transaction (n)  =  T, 
and  we  define  (3\X  to  be  the  subsequence  of  (3  consisting  of  those  serial  actions  7 r  such  that 
object(w)  =  X .  We  define  serial{(3 )  to  be  the  subsequence  of  (3  consisting  of  serial  actions. 

If  (3  is  a  sequence  of  actions  and  T  is  a  transaction  name,  we  say  T  is  an  orphan  in  (3  if  there 
is  an  ABORT (U)  action  in  (3  for  some  ancestor  U  of  T.  We  say  the  T  is  live  in  (3  if  (3  contains 
a  CREATE(T)  event  but  does  not  contain  a  completion  event  for  T. 

2.2.5  Serial  Correctness 

We  use  the  serial  system  to  specify  the  correctness  condition  that  we  expect  other,  more  efficient 
systems  to  satisfy.  We  say  that  a  sequence  (3  of  actions  is  serially  correct  for  transaction  name 
T  provided  that  there  is  some  serial  behavior  7  such  that  f3\T  =  7|T.  We  will  be  interested 
primarily  in  showing,  for  particular  systems  of  automata,  representing  data  objects  that  use 
different  methods  of  concurrency  control  and  a  controller  that  passes  information  between 
transactions  and  objects,  that  all  finite  behaviors  are  serially  correct  for  To. 

We  believe  serial  correctness  to  be  a  natural  notion  of  correctness  that  corresponds  precisely 
to  the  intuition  of  how  nested  transaction  systems  ought  to  behave.  Serial  correctness  for  T  is 
a  condition  that  guarantees  to  implementors  of  T  that  their  code  will  encounter  only  situations 
that  can  arise  in  serial  executions.  Correctness  for  To  is  a  special  case  that  guarantees  that  the 
external  world  will  encounter  only  situations  that  can  arise  in  serial  executions. 

2.3  Review:  Simple  Systems  and  the  Serializability  Theorem 

In  this  section  we  outline  a  general  method  for  proving  that  a  concurrency  control  algorithm 
guarantees  serial  correctness.  This  method  is  treated  in  more  detail  in  [11],  and  is  an  extension 
to  nested  transaction  systems  of  ideas  presented  in  [18,  17].  These  ideas  give  formal  structure 
to  the  simple  intuition  that  a  behavior  of  the  system  will  be  serially  correct  so  long  as  there  is 
a  way  to  order  the  transactions  so  that  when  the  operations  of  each  object  are  arranged  in  that 
order,  the  result  is  legal  for  the  serial  specification  of  that  object’s  type.  For  nested  transaction 
systems,  the  corresponding  result  is  Theorem  2.  Later  in  this  paper  we  will  see  that  the  essence 
of  a  nested  transaction  system  using  locking  algorithms  like  Moss’  is  that  the  serialization  order 
is  defined  by  the  order  in  which  siblings  complete. 

It  is  desirable  to  state  our  Serializability  Theorem  in  such  a  way  that  it  can  be  used  for 
proving  correctness  of  many  different  kinds  of  transaction-processing  systems,  with  radically 
different  architectures.  We  therefore  define  a  “simple  system,”  which  embodies  the  common 
features  of  most  transaction-processing  systems,  independent  of  their  concurrency  control  and 
recovery  algorithms,  and  even  of  their  division  into  modules  to  handle  different  aspects  of 
transaction-processing. 

2.3.1  Simple  Systems 

Many  complicated  transaction-processing  algorithms  can  be  understood  as  implementations  of 
the  simple  system.  For  example,  we  will  see  that  a  system  containing  separate  objects  that 
manage  locks  and  a  “controller”  that  passes  information  among  transactions  and  objects  can 
be  represented  in  this  way. 

’Wo  make  these  definitions  for  arbitrary  sequences  of  actions,  because  we  will  use  them  later  for  behaviors  of 
systems  other  than  the  serial  system. 


We  first  define  an  automaton  called  the  simple  database.  There  is  a  single  simple  database 
for  each  system  type.  The  actions  of  the  simple  database  are  those  of  the  composition  of  the 
serial  scheduler  with  the  serial  objects: 

Input: 

REQUEST.CREATE (T),  for  T^T0 
REQUEST_COMMIT(T,v),  for  T  a  non-access  trans¬ 
action  name,  v  a  value 

Output: 

CREATE(T)  for  T  a  transaction  name 
COMMIT(T),  for  T  f  T0 
ABORT (T),  for  TjLT0 

REPORT_COMMIT(7»,  for  T  ^  T0,  v  a  value 
REPORT_ABORT(T),  for  T  T0 
REQUEST-COMMIT^, u),  for  T  an  access  trans¬ 
action  name,  v  a  value 

The  simple  database  embodies  those  constraints  that  we  would  expect  any  reasonable 
transaction-processing  system  to  satisfy.  It  does  not  allow  CREATE,  ABORT  or  COMMIT 
events  without  an  appropriate  preceding  request,  does  not  allow  any  transaction  to  have  two 
creation  or  completion  events,  and  does  not  report  completion  events  that  never  happened. 
Also,  it  does  not  produce  responses  to  accesses  that  were  not  invoked,  nor  does  it  produce  mul¬ 
tiple  responses  to  accesses.  On  the  other  hand,  the  simple  database  allows  almost  any  ordering 
of  transactions,  allows  concurrent  execution  of  sibling  transactions,  and  allows  arbitrary  re¬ 
sponses  to  accesses.  The  details  can  be  found  in  [11].  We  do  not  claim  that  the  simple  database 
produces  only  serially  correct  behaviors;  rather,  we  use  the  simple  database  to  model  features 
common  to  more  sophisticated  systems  that  do  ensure  correctness. 

A  simple  system  is  the  composition  of  a  strongly  compatible  set  of  automata  consisting  of 
a  transaction  automaton  At  for  each  non-access  transaction  name  T,  and  the  simple  database 
automaton  for  the  given  system  type.  When  the  particular  simple  system  is  understood  from 
context,  we  will  use  the  term  simple  behaviors  for  the  system’s  behaviors. 

The  Serializability  Theorem  is  formulated  in  terms  of  simple  behaviors;  it  provides  a  suf¬ 
ficient  condition  for  a  simple  behavior  to  be  serially  correct  for  a  particular  transaction  name 
T. 


2.3.2  The  Serializability  Theorem 

The  type  of  transaction  ordering  needed  for  our  theorem  is  more  complicated  than  that  used  in 
the  classical  theory,  because  of  the  nesting  involved  here.  Instead  of  just  arbitrary  total  orderings 
on  transactions,  we  will  use  partial  orderings  that  only  relate  siblings  in  the  transaction  nesting 
tree.  Formally,  a  sibling  order  R  is  an  irreflexive  partial  order  on  transaction  names  such  that 
(T,  T')  £  R  implies  parent(T)  =  parent(T'). 

A  sibling  order  R  can  be  extended  in  two  natural  ways.  First,  RtTans  is  the  binary  relation 
on  transaction  names  containing  (T,T')  exactly  when  there  exist  transaction  names  U  and  U' 
such  that  T  and  T'  are  descendants  of  U  and  U'  respectively,  and  (£/,{/')  £  R.  Second,  if  0  is 
any  sequence  of  actions,  then  Revent(0)  is  the  binary  relation  on  events  in  0  containing  (4>,n) 
exactly  when  4>  and  ir  are  distinct  serial  events  in  0  with  lowtransactions  T  and  T1  respectively, 
where  (T,T')  £  Rtram ■  It  is  clear  that  Rtrar.g  and  RCVent(0)  are  irreflexive  partial  orders. 
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In  order  to  state  the  Serializability  Theorem  we  must  introduce  some  technical  definitions. 
Motivation  for  these  can  be  found  in  (11]. 

First,  we  define  when  one  transaction  is  “visible”  to  another.  This  captures  a  conservative 
approximation  to  the  conditions  under  which  the  activity  of  the  first  can  influence  the  second. 
Let  (3  be  any  sequence  of  actions.  If  T  and  T'  are  transaction  names,  we  say  that  T'  is  visible 
to  T  in  (3  if  there  is  a  COMMIT(I/)  action  in  (3  for  every  U  in  ancestors(T')  -  ancestors(T). 
Thus,  every  ancestor  of  T‘  up  to  (but  not  necessarily  including)  the  least  common  ancestor  of 
T  and  T'  has  committed  in  (3.  If  (3  is  any  sequence  of  actions  and  T  is  a  transaction  name,  then 
visible(f3,T )  denotes  the  subsequence  of  (3  consisting  of  serial  actions  7r  with  hightransaction(ft) 
visible  to  T  in  (3. 

We  define  an  “affects”  relation.  This  captures  basic  dependencies  between  events.  For  a 
sequence  (3  of  actions,  and  events  4>  and  ft  in  (3,  we  say  that  (4>,i r)  6  directly-affects((3)  if  at 
least  one  of  the  following  is  true:  transaction (<p)  —  transaction^)  and  <f>  precedes  7 r  in  /?,6 
<f>  =  REQ UEST.CREATE(r)  and  tt  =  CREATE(T),  4>  =  REQUEST_COMMIT(7»  and 
7T  =  COMMIT(T),  <f>  =  REQ U EST.CRE AT E( T )  and  ft  =  ABORT (T),  <p  =  COMMIT(T) 
and  ft  =  REP0RT_C0MMIT(7»,  or  <f>  =  ABORT (T)  and  tt  =  REPORT_ABORT(T).  For  a 
sequence  (3  of  actions,  define  the  relation  affec.ts((3)  to  be  the  transitive  closure  of  the  relation 
directly- a ffccts((3) . 

The  following  technical  property  is  needed  for  the  proof  of  Theorem  2.  Let  (3  be  a  sequence 
of  actions  and  T  a  transaction  name.  A  sibling  order  R  is  suitable  for  (3  and  T  if  the  following 
conditions  are  met. 

1.  R  orders  all  pairs  of  siblings  T'  and  T"  that  are  lowtransactions  of  actions  in  visible(/3,  T). 

2.  Rtventi/3)  and  affects((3 )  are  consistent  partial  orders  on  the  events  in  visible(/3,T). 

The  following  lemma  will  be  used  later  in  proving  that  certain  sibling  orders  are  suitable: 

Lemma  1  Let  (3  be  a  sequence  of  serial  events  and  let  A  be  an  irreflexive  partial  order  on  the 
events  in  (3.  Let  R  be  a  sibling  order  satisfying  the  following  condition:  If  n  and  ft'  are  events 
in  (3  such  that  (ft,  ft')  €  A  and  lowtransaction(ft)  is  neither  an  ancestor  nor  a  descendant  of 
lowlransaclion(ft') ,  then  (ft,  ft')  €  Revent((3)-  Then  Revent((3)  and  A  are  consistent  partial  orders 
on  the  events  of  (3. 

We  introduce  some  terms  for  describing  sequences  of  operations.  For  any  operation  ( T ,  t>) 
of  an  object  A,  let  perform(T,v)  denote  the  sequence  of  actions 
CREATE(T)  REQUEST_C0MM1T(7».  This  definition  is  extended  to  sequences  of  opera¬ 
tions:  if  £  =  f(T,v)  then  perform(£)  =  perform (£')  pcrform(T,v).  A  sequence  £  of  operations 
of  A'  is  serial  object  ivcll-formed  if  no  two  operations  in  £  have  the  same  transaction  name.  Thus 
if  £  is  a  serial  object  well-formed  sequence  of  operations  of  A,  then  perform(^)  is  a  serial  object 
well-formed  sequence  of  actions  of  X.  We  say  that  an  operation  (T,v)  occurs  in  a  sequence  (3 
of  actions  if  a  REQUEST_COMMIT((,T),  v)  action  occurs  in  (3.  Thus,  any  serial  object  well- 
formed  sequence  (3  of  external  actions  of  Sx  is  either  perform (£)  or  per/orm(^)CREATE('F)  for 
some  access  T,  where  £  is  a  sequence  consisting  of  the  operations  that  occur  in  (3. 

Finally  we  can  define  the  “view”  of  a  transaction  at  an  object,  according  to  a  sibling  order 
in  a  behavior.  This  is  the  fundamental  sequence  of  actions  considered  in  the  hypothesis  of 
the  Serializability  Theorem.  Suppose  (3  is  a  finite  simple  behavior,  T  a  transaction  name,  R 
a  sibling  order  that  is  suitable  for  (3  and  T,  and  A  an  object  name.  Let  £  be  the  sequence 

r‘ This  includes  accesses  as  well  as  non-accesses. 
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consisting  of  those  operations  occurring  in  0  whose  transaction  components  are  accesses  to  X 
and  that  are  visible  to  T  in  0,  ordered  according  to  RtTan3  on  the  transaction  components.  (The 
first  condition  in  the  definition  of  suitability  implies  that  this  ordering  is  uniquely  determined.) 
Define  view(0,T,R,X )  to  be  perform (£). 

Theorem  2  (Serializability  Theorem[ll}) 

Let  0  be  a  finite  simple  behavior,  T  a  transaction  name  such  that  T  is  not  an  orphan  in  0,  and 
R  a  sibling  order  suitable  for  0  andT.  Suppose  that  for  each  object  name  X,  view(0,T,  R,X)  G 
finbehs(Sx)-  Then  0  is  serially  correct  for  T . 

3  Assumptions 

In  this  section,  we  present  our  two  main  assumptions.  First,  for  all  of  this  paper  except  Section  6, 
we  will  assume  that  the  fixed  serial  system  (with  respect  to  which  serial  correctness  is  defined) 
contains  only  objects  of  a  particularly  simple  type,  where  the  only  ways  to  access  an  object 
are  to  read  it  or  to  write  it.  This  assumption  reflects  the  reality  at  the  lowest  level  of  many 
database  management  systems,  since  these  are  the  only  accesses  possible  to  a  disk.  While 
many  systems  do  contain  more  complicated  data  types  at  a  higher  level  of  abstraction  (for 
example,  in  a  relational  database  the  accesses  at  the  conceptual  level  include  joins,  selections, 
etc.)  the  assumption  that  all  the  objects  have  this  simple  type  is  usually  made  in  the  classical 
development  of  serializability  theory,  and  we  make  it  here  to  show  the  relationships  between 
our  results  and  the  classical  theory.  In  Section  6  we  remove  this  assumption. 

3.1  Read/Write  Serial  Objects 

Formally,  our  first  assumption  is  that  every  serial  object  in  the  serial  system  is  a  specific  kind 
of  object,  described  below,  which  we  call  a  “read/ write  object.”  That  is,  for  each  object  name 
X  there  is  a  domain  of  values  T>,  a  function  kind  (which  indicates  for  each  access  whether  it  is 
a  read  or  a  write),  a  function  data  (which  indicates  for  each  write  access  the  value  written— in 
our  model,  all  parameters  of  an  access  are  regarded  as  encoded  in  its  name,  so  this  function 
serves  to  decode  one  parameter),  and  an  initial  value  d,  such  that  the  serial  object  automaton 
Sx  has  the  following  state  and  transition  relation.  Its  state  contains  two  components:  active 
(either  nil ,  or  the  name  of  an  access  to  X)  and  data  (an  element  of  V,  representing  the  most 
recently  written  value).  The  start  state  s  has  s. active  =  nil,  and  s.data  —  d.  The  transition 
relation  is  as  follows: 

GREAT  EX?'),  T  an  access  to  X 
Effect: 
s.  active  =  T 

REQUEST_C0MMIT(7»,  T  a  write  access  to  X 
Precondition: 
s'. active  —  T 
v  =  OK 
Effect: 

s.  active  =  nil 
s.data  =  data(T) 
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REQUEST_COMMIT(T,u),  T  a  read  access  to  X 
Precondition: 

s'  .active  =  T 

s'. data  =  v 
Effect: 

s.  active  =  nil 

The  definition  of  the  automaton  Sx  ensures  that,  in  a  serial  system,  each  read  access  returns 
the  most  recent  value  written.  This  can  be  seen  from  the  effects  of  a  REQUEST_COMMIT 
for  a  write  access,  which  stores  the  value  written  by  the  access  in  the  state  component  data , 
and  from  the  preconditions  for  a  REQUEST.COM MIT  for  a  read  access,  which  ensure  that  the 
value  returned  is  the  value  of  the  state  component  data. 

In  the  sequel,  we  will  need  a  definition  for  the  “final  value”  of  a  read/ write  object  after 
a  sequence  of  write  accesses.  If  /?  is  a  sequence  of  serial  actions  and  X  is  an  object  name, 
we  define  write-sequence((3,  X)  to  be  the  subsequence  of  /?  consisting  of  REQUEST.COMMIT 
events  for  transactions  that  are  write  accesses  to  X\  then  we  define  last-write(/3 ,  X )  to  be 
transaction (7r)  where  ir  is  the  last  event  in  write-sequence((3,  X )  (if  write-sequence((3,X)  is 
empty,  last-write(/3 ,  X)  is  undefined.)  Finally,  we  define  final- value((3,X)  to  be  the  initial  value 
d  if  last-write((3,X)  is  undefined,  and  data(last-write(/3 ,  X))  otherwise.  Thus,  final-value(/3,  X) 
is  the  latest  value  written  in  fi  for  X.  The  following  lemmas  characterize  the  state  and  behaviors 
of  the  read/ write  object  Sx  in  terms  of  final-value: 

Lemma  3  Let  (3  be  a  finite  schedule  of  read/write  serial  object  Sx,  and  let  s  be  the  (unique) 
state  of  Sx  after  (3.  Then  s.data  =  final-value(/3,  Sx)- 

Lemma  4  Let  (3  be  a  finite  behavior  of  Sx-  Then  (3perform(T,v)  is  a  behavior  of  Sx  exactly 
when  either  T  is  a  write  access  to  X  and  v  =  OK,  or  T  is  a  read  access  to  X  and  v  = 
final-value((3,X). 

3.2  Appropriate  Return  Values 

In  a  real  transaction- processing  system,  different  transactions  can  access  an  object  concurrently. 
Concurrency  control  and  recovery  algorithms  are  needed  to  ensure  that  the  effect  of  a  concurrent 
execution  is  the  same  as  that  of  some  execution  of  the  serial  system,  as  far  as  the  users  of  the 
system  can  observe.  Rather  than  developing  a  complex  model  of  a  real  transaction-processing 
system,  we  prove  results  about  behaviors  of  simple  systems  satisfying  certain  restrictions;  we 
then  show  that  a  particular  real  transaction-processing  system  implements  the  simple  system 
(so  each  of  its  behaviors  is  also  a  simple  behavior)  and  that  its  behaviors  satisfy  the  necessary 
restrictions.  One  advantage  of  this  approach  is  that  it  allows  us  to  make  very  few  assumptions 
about  the  structure  of  a  transaction-processing  system;  instead,  we  make  assumptions  about  its 
behaviors,  represented  as  simple  behaviors. 

In  defining  these  assumptions,  and  in  the  remainder  of  the  paper,  we  will  apply  the  defini¬ 
tions  above  of  write-sequence,  last-write,  and  final-value  to  behaviors  of  simple  systems.  Notice 
that  each  of  these  was  defined  in  terms  of  general  sequences  of  serial  actions,  so  applying  them 
to  simple  behaviors  does  not  cause  any  problems. 

Our  first  assumption  described  above,  namely  that  each  serial  object  is  a  read/write  ob¬ 
ject,  applies  to  serial  systems.  Our  second  assumption  applies  to  behaviors  of  simple  systems. 
Informally,  we  assume  the  existence  of  some  underlying  recovery  system  that  ensures  that  de¬ 
scendants  of  aborted  and  uncommitted  transactions  appear  never  to  have  happened;  once  the 
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actions  of  these  transactions  have  been  removed  from  consideration,  the  return  value  for  an 
access  is  what  one  would  expect  from  a  simplistic  model  of  the  simple  system,  where  each 
object’s  value  is  stored  in  a  location,  being  overwritten  with  a  new  value  by  write  accesses  and 
unaffected  by  read  accesses.  Much  of  the  classical  work  on  concurrency  control  has  used  this 
simplistic  model  without  comment. 

To  make  this  formal,  we  introduce  a  definition:  if  0  is  a  simple  behavior,  then  we  say  that  0 
has  appropriate  return  values  provided  that  whenever  7r  is  a  REQUEST_COMMIT(T,t;)  event 
occurring  in  visible)0  ,Tq)  and  T  is  an  access  to  an  object  X,  then  either  T  is  a  write  access  and 
v  =  OK ,  or  T  is  a  read  access  and  v  =  final-value(6,X),  where  6  is  the  prefix  of  visible)0,To) 
preceding  x.  Notice  that  we  here  restrict  attention  to  the  part  of  the  sequence  0  that  is  visible 
to  To.  This  restriction  corresponds  to  the  classical  theory’s  focus  on  the  “permanent”  part  of 
the  computation  (called  the  “committed  projection”  in  [3]) — the  part  that  has  committed  to 
the  outside  world. 

The  following  is  a  convenient  characterization  of  appropriate  return  values  for  systems  in 
which  all  serial  objects  are  read/write  objects. 

Lemma  5  Let  0  be  a  finite  simple  behavior.  Then  0  has  appropriate  return  values  if  and  only 
if  per form)operations)visible{0  ,Tq))\X)7  is  a  behavior  of  Sx  for  all  X. 

Proof:  Suppose  0  has  appropriate  return  values  and  X  is  an  object  name.  We  must  show  that 
perform)operations)visible)0,To)\X ))  is  a  behavior  of  Sx-  We  show  the  equivalent  statement 
that  for  any  prefix  £  of  operations)visible(0,To)\X ),  perform)^ )  is  a  behavior  of  Sx,  which 
we  do  by  induction  on  the  number  of  operations  in  £.  The  base  case,  when  there  are  no 
operations,  is  trivial.  Otherwise  £  =  £'(T,  v).  By  the  induction  hypothesis,  perform (£')  is  a 
behavior  of  Sx-  Now  since  (T,  v)  is  in  operations) visible)0, To)| X),  we  see  that  T  is  an  access 
to  X  and  there  is  an  event  7r  =  REQUEST_COMMIT(T,u)  in  visible)0,To).  Since  0  has 
appropriate  return  values,  either  T  is  a  write  access  and  v  =  OK,  or  T  is  a  read  access  and 
v  =  final-value)6,  Sx),  where  6  is  the  prefix  of  visible{0 ,Tq)  preceding  it.  In  the  case  where  T  is 
a  read  access,  then  we  note  that  write-sequence)b ,  S x)  —  write-sequence(perform(£'),  Sx)  and 
so  final-value)6,Sx)  =  final-value)perform)ft'),Sx)-  Thus  perform(£(T,v))  is  a  behavior  of  Sx 
by  Lemma  4. 

Conversely,  suppose  perform)operations)visible)0,To)\X))  is  a  behavior  of  Sx  for  all  X. 
Consider  n,  a  REQUEST_COMMIT(T,u)  event  occurring  in  visible)0,To)\X  where  T  is  an 
access.  We  must  have  (T,  v)  in  operations)visible{0,To)\X ),  where  object{T)  =  X.  Let  £'  be 
the  prefix  of  operations)visible)0 ,  To)|X)  preceding  (T,  u).  Since  perform)£')T,  u))  is  a  behavior 
of  Sx,  by  Lemma  4  we  conclude  that  either  T  is  a  write  access  and  v  =  OK,  or  T  is  a  read 
access  and  v  =  final-value(perform(£'),  Sx)-  However,  we  note  that  if  6  is  the  prefix  of  vis- 
ible(0,  To)  preceding  ic,  then  write- sequence)^,  S x)  =  write- sequence)  perform)^'),  Sx)  and  so 
final- value)6,  Sx)  =  final- value)perform{£'),  Sx)-  Thus,  either  T  is  a  write  access  and  v  =  OK , 
or  T  is  a  read  access  and  v  =  final- value )6,  Sx)-  Since  7r  was  arbitrary,  0  has  appropriate  return 
values.  □ 


3.3  A  Sufficient  Condition  for  Appropriate  Return  Values 

The  hypothesis  that  a  system’s  behaviors  have  appropriate  return  values  is  commonly  made, 
and  in  the  classical  development  of  serializability  theory  it  is  usually  regarded  as  axiomatic. 

7An  “operation”  is  a  pair  (7  ,  v);  the  operator  “operations”  extracts  the  sequence  of  operations  corresponding 
to  the  REQUEST-COMMIT  events  in  an  event  sequence. 
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However  when  one  studies  or  designs  a  real  system  one  must  consider  how  particular  algorithms 
lead  to  this  hypothesis  being  met.  For  write  accesses  it.  is  certainly  easy  to  ensure  that  the  return 
value  is  OK.  However  the  situation  with  read  accesses  is  very  different.  In  this  section,  we 
define  simple  conditions  that  are  sufficient  to  ensure  appropriate  return  values.  While  these 
conditions  are  not  only  sufficient  and  not  necessary,  they  do  apply  to  many  algorithms. 

We  need  to  show  the  following:  for  every  REQUEST_COMMIT(T,v)  event  7r  in  visible(0,  T0), 
where  T  is  a  read  access  to  X ,  the  return  value  v  is  equal  to  final-value(6,  X),  where  6  is  the 
prefix  of  visible(/3,7o)  preceding  7 r.  Now,  at  the  time  t  occurs,  the  sequence  6  is  not  yet  deter¬ 
mined,  since  it  depends  on  all  the  COMMIT  events  in  /?,  including  those  that  follow  ir.  It  is 
useful  to  have  conditions  that  can  be  checked  when  tt  occurs  and  that  are  sufficient  to  ensure 
appropriate  return  values.  We  define  two  conditions.  The  first  requires  that  the  return  value 
for  a  REQUEST.COMMIT  event  be  “current”  using  the  sequence  of  events  that  occur  before 
the  REQUEST.COMMIT  event.  Informally,  a  REQUEST.COMMIT  event  for  a  read  access  is 
current  if  the  return  value  provides  the  appearance  of  accessing  a  variable  that  is  overwritten 
when  each  new  write  access  requests  to  commit  and  is  restored  when  a  transaction  ABORT 
occurs  in  order  to  remove  all  trace  of  the  descendants  of  the  aborted  transaction.  The  second 
condition  requires  that  the  return  value  be  “safe,”  in  the  sense  that  all  the  needed  COMMIT 
events  are  already  present  in  the  sequence  before  the  REQUEST.COMMIT.  Informally,  a 
REQUEST.COMMIT  event  for  a  read  access  is  safe  if  the  writer  of  the  current  value  (under 
the  assumption  that  there  is  a  current  value  that  is  overwritten  and  restored)  is  visible  to  the 
reader.  This  ensures  that  any  ancestor  of  the  writer  that  is  not  yet  committed  is  also  an  ances¬ 
tor  of  the  reader.  Thus,  the  writer  cannot  be  aborted  (by  aborting  one  of  its  ancestors)  without 
also  aborting  the  reader.  A  read  access  that  is  not  safe  is  sometimes  described  as  reading  “dirty 
data.” 

More  formally,  if  0  is  any  sequence  of  serial  actions,  we  define  clean(0)  to  be  the  subse¬ 
quence  of  0  containing  all  events  whose  hightransactions  are  not  orphans  in  0.  Then  if  0  is 
a  sequence  of  serial  actions  and  X  is  an  object  name,  we  define  elean-write-sequence(0 ,  X)  to  be 
write-sequence(clean(0),X).  Also,  we  define  clean-last-write(0,  X)  to  be  last-write(clean(0),  X). 
Similarly,  we  define  clean- final-value(0 ,  X)  to  be  final-value(clean(0) ,  X). 

Now,  if  0  is  a  sequence  of  serial  actions  and  7r  is  a  REQUEST_COMMIT(T,v)  event  that 
appears  in  0,  where  T  is  a  read  access  to  X,  then  we  say  that  tt  is  current  in  ft  if  v  = 
clean-final-value{0' ,  X ) ,  where  0'  is  the  longest  prefix  of  0  that  does  not  include  the  event 
7r.  In  addition,  if  0  is  a  sequence  of  serial  actions  and  7r  is  a  REQUEST.COMMIT^, u) 
event  that  appears  in  0 ,  where  T  is  a  read  access  to  X,  then  we  say  that  7r  is  safe  in  0  if 
clean-last-write(0' ,  A)  is  either  undefined  or  visible  to  T  in  /?',  where  0'  is  the  longest  prefix  of 
0  that  does  not  include  the  event  7r. 

We  have  the  following  key  lemma. 

Lemma  6  Let  0  be  a  simple  behavior  such  that  the  following  hold. 

1.  If  n  is  a  REQUEST.COMMITfT  ,v)  event  that  occurs  in  visible(0, T0)  where  T  is  a  write 
access  to  X ,  then  v  =  OK. 

2.  If  tt  is  a  REQUEST.COMMIT(T  ,v)  event  that  occurs  in  visible(0,To)  where  T  is  a  read 
access  to  X ,  then  tt  is  current  and  safe  in  0. 

Then  0  has  appropriate  return  values. 

Proof:  Condition  (1)  above  is  the  first  condition  needed  to  argue  that  0  has  appropriate 
return  values.  It  remains  to  show  that  if  7r  a  REQUEST_C0MMIT(7\u)  event  that  occurs 
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in  visible(f),  7’q)  where  T  is  a  read  access  to  X,  and  ir  is  current  in  /?  and  safe  in  (i,  then 
v  —  final-value(6,  Sx)  where  6  is  the  prefix  of  visible(/3,  To)  preceding  ir. 

Now,  if  ir  is  current  in  (3  then  by  definition  v  =  clean-final-value(f3' ,  Sx)  where  /?'  is  the  prefix 
of  (3  preceding  t.  Thus  we  need  only  prove  that  clean-last- write{f3' ,  Sx)  —  last-write(6 ,  S x) ■ 
Since  (3  is  a  simple  behavior  (and  so  does  not  contain  both  a  COMMIT  and  an  ABORT  for  any 
transaction),  any  transaction  that  is  visible  to  To  in  (3  is  not  an  orphan  in  f3 ,  and  hence  is  not 
an  orphan  in  f3‘.  Thus  write-sequence(6,  Sx)  is  a  subsequence  of  clean- write- sequence((3' ,  S x). 

We  will  show  that  the  last  event  in  clean- write- sequence(j3\  Sx)  if  any,  does  occur  in  6.  Note 
that  this  last  event  is  a  REQUEST_COMMIT  for  clean-last- write{(3' ,  S x)-  By  the  hypothesis 
that  7 r  is  safe,  we  see  that  clean-last-write((3' ,  Sx)  is  visible  to  T  in  (3 ',  and  hence  in  /3.  Since  ix  oc¬ 
curs  in  visible(/3 ,  To)  we  have  that  T  is  visible  to  To  in  /3.  We  deduce  that  clean- last-writc{(3' ,  Sx) 
is  visible  to  To  in  /?,  and  so  the  last  event  in  clean-write-sequencc((3' ,  Sx )  occurs  in  visible((3 ,  Sx)- 
Since  it  precedes  x,  it  occurs  in  6  as  claimed.  Now  (as  it  is  a  REQUESTX’OMMIT  for  a  write  ac¬ 
cess  to  X)  we  can  deduce  it  will  occur  in  write-sequence(6 ,  Sx)-  Further,  since  the  order  of  events 
in  write-sequence(6,  Sx)  is  the  same  as  the  order  of  those  events  in  clean-wrile-sequcnce(l3' ,  Sx) 
(each  order  is  just  the  order  in  /?),  it  must  be  the  last  event  as  required.  □ 

4  The  Serialization  Graph  Construction 

In  this  section,  we  present  our  serialization  graph  construction.  Recall  that  the  serial  correctness 
condition  of  [11]  embodies  not  only  the  serializability  condition  of  the  classical  theory,  but  also 
the  external  consistency  condition.  Therefore,  our  serialization  graphs  will  have  two  kinds  of 
edges,  “conflict  edges”  and  “precedence  edges.”  The  former  are  similar  to  those  used  in  the 
classical  theory,  and  serve  to  fix  the  order  of  conflicting  operations.  The  latter  are  added  to 
capture  restrictions  required  for  external  consistency. 

We  define  a  conflict  relation  between  accesses  so  that  two  write  accesses  to  the  same  object 
conflict,  as  do  a  write  and  a  read  access  to  the  same  object,  but  not  two  read  accesses  or  two 
accesses  to  different  objects.  More  formally,  let  Sx  be  a  serial  object  for  object  name  X,  and 
let  T  and  T'  are  accesses  to  A".  Then  we  say  that  T  and  T'  conflict  if  either  T  or  T'  is  a  write 
access. 

We  extend  the  preceding  definition  to  a  conflict  relation  on  operations :  if  Sx  is  a  serial 
object  for  object  name  X,  (T,n)  and  ( T',v ')  are  operations  where  T  and  T'  are  accesses  to 
A',  then  we  say  that  (T,  v)  and  (T',v')  conflict  if  and  only  if  T  and  T'  conflict.  The  following 
proposition  shows  that  non-conflicting  operations  can  be  reordered  in  serial  behaviors: 

Proposition  7  Suppose  that  £  is  a  sequence  of  operations  of  X  such  that  perform (£)  is  a  serial 
object  well-formed  behavior  of  Sx-  Suppose  that  q  is  a  reordering  of  £  such  that  all  pairs  of 
conflicting  operations  occur  in  the  same  order  in  ij  and  in  Then  perform(q)  is  a  behavior  of 

Sx- 


We  next  derive  a  conflict  relation  between  sibling  transactions,  based  on  conflicts  between 
descendant  operations.  Formally,  if  [3  is  a  sequence  of  serial  actions,  we  define  conflict (/3)  to  be 
the  relation  such  that  (T,T')  €  conflict({3)  if  and  only  if  7’  and  T'  are  siblings  and  the  following 
holds:  there  are  events  4>  and  <f>'  in  visible(/3,T0)  such  that  </>  =  REQUEST_COMMIT(f/,n) 
where  U  is  a  descendant  of  T,  <f>'  -  REQUEST-COMMI'l^T',?)')  where  V  is  a  descendant 
of  T',  {U,v)  conflicts  with  (U',v')  and  4>  precedes  ft  in  visiblc((3,To).  Informally,  T  conflicts 
with  V  if  a  descendant  of  T'  accesses  some  object  A'  after  a  descendant  of  /'  accesses  .V  in  a 
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conflicting  manner  (i.e.,  at  least  one  access  is  a  write).  Note  that  if  two  siblings  are  related  by 
conflict(P)  then  they  (and  thus  their  common  parent)  are  visible  to  To  in  f3. 

If  f3  is  a  sequence  of  serial  actions,  define  precedes(fi)  to  be  the  relation  such  that  (T,  T')  6 
precedes((3 )  if  and  only  if  T  and  T'  are  siblings  whose  common  parent  is  visible  to  To  in  /?,  and 
a  report  event  for  T  and  a  REQUEST.CREATE(T')  occur  in  /3,  in  that  order.  Informally,  T 
precedes  V  if  their  parent  knows  that  T  finished  before  it  requests  the  creation  of  V . 

If  (5  is  a  sequence  of  serial  actions,  we  incorporate  the  information  in  the  relations  conflict (/?) 
and  precedes(fi)  into  a  graph,  as  follows.  We  define  the  serialization  graph  SG((3)  to  be  the 
union  of  a  collection  of  disjoint  directed  graphs  SG(/3,T),  one  for  each  transaction  T  that  is 
visible  to  To  in  f3.  The  graph  SG((3,T )  has  nodes  labelled  by  the  children  of  T,  and  a  directed 
edge  from  the  node  labelled  T'  to  the  node  labelled  T"  if  and  only  if  T'  and  T"  are  children  of 
T  and  (T',T")  6  precedes((3 )  U  conflict(fi). 

The  following  theorem  gives  a  sufficient  condition  for  a  sequence  f3  of  serial  actions  to  be 
serially  correct  for  To.  It  relies  on  our  Serializability  Theorem  (Theorem  2). 

Theorem  8  Let  (3  be  a  finite  simple  behavior  that  has  appropriate  return  values.  Suppose  that 
SG((3)  is  acyclic.  Then  (3  is  serially  correct  for  To- 

Proof:  For  each  transaction  T  that  is  visible  to  To  in  (3,  we  can  choose  some  total  order  on 
the  children  of  T  that  is  a  topological  sort  of  the  directed  graph  SG(P,T),  since  that  graph 
is  acyclic.  Let  R  denote  the  sibling  order  given  by  the  union  of  the  chosen  total  orders.  We 
claim  that  R  is  suitable  for  /3  (as  defined  in  Section  2.3)  and  that  for  every  object  name  X, 
view(fi,  T0,  R,  X)  is  a  behavior  of  Sx •  Once  we  have  shown  the  truth  of  these  claims,  Theorem  2 
(the  Serializability  Theorem  of  [11] — in  Section  2.3)  completes  the  proof. 

To  show  that  R  is  suitable  we  need  to  check  that  it  orders  all  pairs  of  siblings  T  and  T'  that 
are  lowtransactions  of  events  in  visible((3,To),  and  that  Rcvent(P )  and  affects(fi)  are  consistent 
partial  orders  on  the  events  in  visible(fi,  T0). 

By  construction,  R  orders  all  pairs  of  siblings  whose  common  parent  is  visible  to  To  in  (3.  We 
argue  that  this  includes  all  pairs  of  siblings  that  are  lowtransactions  of  actions  in  visible(/3,  To) 
as  follows:  the  hightransaction  of  an  action  in  visible((3,  To)  is  visible  to  To  in  /?,  and  the  parent 
of  an  action’s  lowtransaction  is  either  the  action’s  hightransaction  (for  completion  actions)  or 
the  parent  of  the  action’s  hightransaction  (for  other  actions).  Since  the  action’s  hightransaction 
is  visible  to  To  in  (3,  so  is  the  parent  of  the  action’s  hightransaction.  Thus  R  orders  all  pairs  of 
siblings  T  and  V  that  are  lowtransactions  of  events  in  visible((3,To). 

Suppose  that  ic  and  ir'  are  events  in  visible((3  ,To)  such  that  %  affects  ir'  in  (3  and 
lowtransaction( 7r)  is  neither  an  ancestor  nor  a  descendant  of  lowtransaction{x').  It  is  easy  to 
show  that  there  must  be  a  common  ancestor  T  of  lowtransaction (:r)  and  lowtransaction (tt') 
such  that  a  report  event  for  T\  precedes  a  REQUEST-CREATED)  event  in  (3 ,  where  T\ 
and  Tj  are  the  children  of  T  that  are  ancestors  of  lowtransaction(n)  and  lowtransaction(n'), 
respectively.  It  follows  that  (TiD)  €  precedes(fi).  Since  R  was  chosen  using  a  topological  sort 
of  the  graphs  SG(0,T),  precedes(fi)  C  R.  Thus  ( TjD )  €  R,  and  so  (zr, zr')  6  Revent(f3)-  It 
follows  from  Lemma  1  that  Reveni{(3)  and  affec.ts{(3 )  are  consistent  partial  orders  on  the  events 
in  visible((3,  To).  Thus  R  is  suitable  for  (3. 

Now  let  X  be  an  object  name.  We  must  show  that  7  =  view(/3,To,  R,  X)  is  a  behador  of 
Sx-  Lemma  5  implies  that  perform(operations(visible([3,To)\X))  is  a  behavior  of  Sx-  Now  7 
is  of  the  form  perform((7\,  tqJD,  v2)  •  •  -(Tn,  t;n)),  where  the  ( Ti,V{ )  are  the  operations  of  X 
that  occur  in  visiblc((3,T0),  and  (T,-,  Ti+ 1)  €  Rtrant  for  every  i  from  1  to  n  —  1  inclusive.  We 
make  the  claim:  If  T,  conflicts  with  Tj  and  i  <  j,  then  REQUEST_COMMIT(T,,u,)  precedes 
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REQUEST_C0MMIT(7j,i;j)  in  visible((3,T0).  In  other  words,  7  can  be  obtained  from  per- 
form(operations(visible(P,To)\X))  simply  by  reordering  non-conflicting  operations. 

The  claim  is  proved  as  follows:  Since  REQUEST_COMMIT(T,,  v;)  and  REQUEST.COM- 
MIT(Tj,  Vj)  both  occur  in  visible{(i  ,Tq)  it  is  enough  to  show  that  REQUEST_C0MM1T(T,,  vt) 
does  not  precede  REQUEST_C0MMIT(7j,  Vj )  in  visible((3,T0).  Suppose  it  did.  Then  letting 
U  and  U'  denote  the  children  of  lca(T{,Tj)  that  are  ancestors  of  T,  and  Tj  respectively,  we 
would  have  (£/',  U)  €  conflict^),  and  so  (U',  U )  6  SG(/3,  lca(T{,Tj))  and  therefore  (U',U)  €  R. 
Thus  ( Tj,Ti )  €  Rtrans,  contradicting  (T,,Tj)  €  Rtmns  which  follows  from  i  <  j.  Thus  the  claim 
is  established. 

By  definition,  the  operations  in  operations(visible((3,To)\X)  are  exactly  the  same  as  those 
in  the  sequence  (Tj,  v i)(72,  V2) .  .  .(Tn,  vn).  Moreover,  as  the  claim  above  asserts,  conflicting  op¬ 
erations  occur  in  the  same  order.  Therefore,  by  Proposition  7  and  the  fact  that  perform(opera- 
tions(visible(0,To)\X))  is  a  behavior  of  Sx ,  we  have  that  7  is  a  finite  behavior  of  Sx- 

Theorem  2  then  implies  the  result.  □ 


5  Moss’  Algorithm 

In  this  section  we  use  the  serialization  graph  described  above  to  prove  the  correctness  of  Moss’ 
algorithm  for  read/write  locking  [13],  the  basic  concurrency  control  mechanism  in  the  Argus 
and  Camelot  systems. 

5.1  Generic  Systems 

First  we  describe  one  way  to  model  a  transaction-processing  system  that  includes  concurrency 
control  and  recovery  algorithms.  We  will  model  such  a  system  as  a  “generic  system,”  which  is 
composed  of  transaction  automata,  “generic  object  automata”  and  a  “generic  controller.”  In 
this  paper,  we  include  only  a  sketch;  complete  definitions  appear  in  [4]. 

Unlike  the  serial  object  for  X ,  the  corresponding  generic  object  is  responsible  for  carrying  out 
the  concurrency  control  and  recovery  algorithms  for  X,  for  example  by  maintaining  lock  tables. 
In  order  to  do  this,  the  automaton  requires  information  about  the  completion  of  some  of  the 
transactions,  in  particular,  those  that  have  visited  that  object.  Thus,  a  generic  object  automa¬ 
ton  has  (besides  the  CREATE  and  REQUEST.COMMIT  actions)  special  INEORMXOMMIT 
and  INFORM_ABORT  input  actions  to  inform  it  about  the  completion  of  (arbitrary)  transac¬ 
tions. 

There  is  a  single  generic  controller  for  each  system  type.  It  passes  requests  for  the  creation 
of  subtransactions  to  the  appropriate  recipient,  makes  decisions  about  the  commit  or  abort 
of  transactions,  passes  reports  about  the  completion  of  children  back  to  their  parents,  and 
informs  objects  of  the  fate  of  transactions.  Unlike  the  serial  scheduler,  it  does  not  prevent 
sibling  transactions  from  being  active  simultaneously,  nor  does  it  prevent  the  same  transaction 
from  being  both  created  and  aborted.  Rather,  it  leaves  the  task  of  coping  with  concurrency 
and  recovery  to  the  generic  objects. 

A  generic  system  of  a  given  system  type  is  the  composition  of  a  strongly  compatible  set 
of  automata  consisting  of  the  transaction  automaton  At  for  each  non-access  transaction  name 
T  (this  is  the  same  automaton  as  in  the  serial  system),  a  generic  object  automaton  Gx  for 
each  object  name  X,  and  the  generic  controller  automaton  for  the  system  type.  The  external 
actions  of  a  generic  system  are  called  generic  actions ,  and  the  executions,  schedules  and  behav¬ 
iors  of  a  generic  system  are  called  generic  executions ,  generic  schedules  and  generic  behaviors, 
respectively. 
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5.2  A  Read/Write  Locking  Object  Automaton 

We  model  a  system  using  Moss’  algorithm  as  a  generic  system  in  which  every  generic  object 
automaton  is  the  “read/write  locking  object  automaton”  Mix  described  below,  derived  from 
the  appropriate  serial  object  Sx •  The  automaton  Mix  maintains  a  stack  of  “values,”  and 
manages  “read  locks”  and  “write  locks.”8 

We  give  here  the  definition  of  the  read/write  locking  object  Mix-  Mix  has  the  usual 
external  actions  for  a  generic  object  automaton  for  X,  and  it  has  no  internal  actions.  A  state  s  of 
Mix  has  components  s. created,  s. commit-requested,  s.write-lockholders  and  s.read-lockholders, 
all  sets  of  transactions,  and  s. value,  which  is  a  function  from  s.write-lockholders  to  V,  the 
domain  of  basic  values.  We  say  that  a  transaction  in  write-lockholders  holds  a  write-lock,  and 
similarly  that  a  transaction  in  read-lockholders  holds  a  read-lock.  The  start  states  of  Mix  are 
those  in  which  write-lockholders  =  {To}  and  value(To)  is  d  (the  initial  value  of  Sx),  and  the 
other  components  are  empty. 

The  transition  relation  of  Mix  is  as  follows. 

CREATE(T),  T  an  access  to  X 
Effect: 

s. created  =  s'. created  U  {T} 

INFORM_COMMIT_AT(X)OF(T),  T^T0 
Effect: 

if  T  6  s'  .write-lockholders 
then 

s.write-lockholders  =  (s' .write-lockholders  -  {T}) 

U{parent(T)} 

s.value(parent(T ))  =  s’.value(T) 
s.value(U)  =  s'  .value(U), 

for  U  €  s.write-lockholders  —  { parent(T )} 
if  T  €  s'  .read-lockholders 

then  s.read-lockholders  =  (s' .read-lockholders  -  {T}) 

U{parenf(T)} 

INFORM_ABORT_AT(A)OF(T),  T  #  T0 
Effect: 

s.write-lockholders  = 

s'  .write-lockholders  —  descendants(T) 
s.read-lockholders  — 

s'  .read-lockholders  -  descendants(T) 
s.value(U)  =  s’.value(U)  for  all  U  G  s.write-lockholders 

REQUEST_COMMIT(T,v),  T  a  read  access  to  X 
Precondition: 

T  G  s'. created  -  s'  .commit-requested 
s'  .write-lockholders  C  ancestors(T) 
v  =  s'.i >alue(least(s'  .write-lockholders)) 

Effect: 

®This  automaton  is  a  simplification  of  the  read/update  locking  automaton  Mx  defined  in  [4].  The  latter  is 
defined  for  any  serial  object,  rather  than  the  particular  read/write  serial  object  defined  in  this  paper. 
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s.  commit-requested  =  s'  .commit-requested  U  {T} 
s.read-lockholders  =  s' .read-lockholders  U  { T } 

REQUEST_COMMIT(T,t;),  T  a  write  access  to  X 
Precondition: 

T  €  s'. created  -  s'  .commit-requested 
s'  .write-lockholders  U  s' .read-lockholders  C  ancestors(T) 
v=  OK 
Effect: 

s. commit-requested  =  s'  .commit-requested  U  {T} 
s.  write-lockholders  =  s'  .write-lockholders  U  {T} 
s.value(T )  =  data(T) 
s.value(U)  =  s'.value(U), 

for  all  U  €  s. write-lockholders  -  {T} 

When  an  access  transaction  is  created,  it  is  added  to  the  set  created.  When  Mix  is  informed 
of  a  commit,  it  assigns  any  locks  held  by  the  transaction  to  the  parent,  and  also  assigns  any 
stored  value  to  the  parent.  When  Mix  is  informed  of  an  abort,  it  discards  all  locks  held  by 
descendants  of  the  transaction.  A  response  to  an  access  T  can  be  returned  only  if  the  access 
has  been  created  but  not  yet  responded  to,  every  holder  of  a  conflicting  lock  is  an  ancestor  of  T, 
and  the  return  value  is  appropriate,  being  OK  for  a  write  access  and  the  value  corresponding 
to  the  least  holder  of  a  write  lock  if  the  access  is  a  read.  (The  component  s. write-lockholders 
will  always  be  a  linear  chain  of  transactions,  with  every  element  being  either  an  ancestor  or 
descendant  of  every  other.  The  least  element  of  such  a  set  is  the  unique  descendant  of  all 
other  elements.)  When  this  response  is  given,  T  is  added  to  commit-requested  and  granted  the 
appropriate  lock.  Also,  if  T  is  a  write  access,  the  new  value  is  stored  as  value{T),  while  if  T  is 
a  read  access,  no  change  is  made  to  value. 

5.3  Basic  Properties  of  M 1*. 

We  begin  with  some  basic  properties  of  Mix •  These  can  be  proved  by  common  techniques 
such  as  invariant  assertions  or  arguments  about  sequences  of  actions. 

The  statements  of  the  results  below  use  some  terminology  about  the  information  about 
the  status  of  transactions  that  is  deducible  from  the  behavior  of  Mix-  If  /?  is  a  sequence  of 
actions  of  Mix,  and  T  and  T'  are  transaction  names  we  say  that  T  is  a  local  orphan  at  X 
in  0  if  an  INFORM_ABORT_AT(X)OF({/)  event  occurs  in  0  for  some  ancestor  U  of  T,  and 
we  say  that  T  is  lock-visible  at  X  to  T'  in  0  if  0  contains  a  subsequence  0'  consisting  of  an 
INFORM_COMMIT_AT(A’)OF(f/')  event  for  every  U  €  ancestors{T)  -  ancestors(T'),  arranged 
in  ascending  order  (so  the  INFORM_COMMIT  for  parent(U)  is  preceded  by  that  for  U ).  If  0 
is  a  behavior  of  a  generic  system,  we  note  that  T  is  lock-visible  to  T  at  X  in  0\Mlx  only  if  T 
is  visible  to  V  in  0.  Similarly  T  is  a  local  orphan  at  X  in  0\Mlx  only  if  T  is  an  orphan  in  0. 

First  we  have  a  fundamental  invariant  of  the  state  of  Mix,  which  expresses  the  fact  that 
conflicting  locks  are  never  held  by  transactions  except  when  one  transaction  is  the  ancestor  of 
the  other.  This  condition  is  enforced  when  locks  are  granted,  and  preserved  thereafter  by  all 
actions. 

Lemma  9  Let  0  be  a  finite  schedule  of  Mix  ■  Suppose  0  can  leave  Mix  in  state  s,  and  that 
T  €  s. write-lockholders  and  T'  6  s.read-lockholders  U  s. write-lockholders.  Then  either  T  is  an 
ancestor  ofT'  or  else  T'  is  an  ancestor  ofT. 
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The  following  lemma  shows  which  transactions  hold  locks  after  a  schedule  of  Mix- 

Lemma  10  Let  (3  be  a  finite  schedule  of  Mix  ■  Suppose  that  (3  can  leave  Mix  *n  state  s.  Let  T 
be  an  access  to  X  such  that  REQUEST JSOMMlT(T ,v)  occurs  in  (3  and  T  is  not  a  local  orphan 
in  ft,  and  let  T'  be  the  highest  ancestor  of  T  such  that  T  is  lock-visible  to  T'  in  (3.  If  T  is  a 
write  access  then  T'  €  s. write- lockholders.  IfT  is  a  read  access  then  T'  G  s.read-lockholders. 

The  following  lemma  shows  that  when  an  access  T'  occurs,  all  prior  conflicting  accesses 
must  either  be  local  orphans  or  lock-visible  to  T’. 

Lemma  11  Let  ft  be  a  generic  object  well-formed  schedule  of  Mix-  Suppose  distinct  events 
tt  =  REQ UES T. COMMIT (T,v)  and  tt'  =  REQU EST.COM M IT (T' ,v' )  occur  in  (3,  where  T  and 
T'  conflict.  If  7r  precedes  tt'  in  (3  then  either  T  is  a  local  orphan  in  (3 '  or  T  is  lock-visible  to  T' 
in  [3' ,  where  (3'  is  the  prefix  of  / 3  preceding  tt'. 

The  following  lemma  characterizes  the  value  component  of  the  state,  showing  that  value(T) 
reflects  the  effects  of  all  transactions  that  are  lock-visible  to  T. 

Lemma  12  Let  f3  be  a  finite  generic  object  well-formed  schedule  of  Mix  ■  Suppose  that  (3  can 
leave  Mix  state  s.  Let  T  be  a  transaction  name  that  is  not  a  local  orphan  in  (3  such  that 
T  €  s.write-lockholders.  Then  s.value(T)  =  final-value(6,  X),  where  6  is  the  subsequence  of  (3 
consisting  of  events  it  such  that  transaction^)  is  lock-visible  to  T  in  (3. 

From  the  previous  lemma,  we  can  show  a  more  general  characterization. 

Lemma  13  Let  (3  be  a  finite  generic  object  well-formed  schedule  of  Mix-  Suppose  that  (3 
can  leave  Mix  in  state  s.  Let  T  be  a  transaction  name  that  is  not  a  local  orphan  in  (3, 
and  let  U  denote  the  least  ancestor  of  T  such  that  U  €  s.write-lockholders.  Then  s.value(U)  — 
final-value(j,X),  where  7  is  the  subsequence  of  (3  consisting  of  events  tt  such  that  transaction (7r) 
is  lock-visible  to  T  in  (3. 

5.4  Correctness  Proof  of  Read/Write  Locking 

Consider  a  generic  system  in  which  each  generic  object  is  M  lx  for  the  appropriate  object  name 
X.  We  will  use  Theorem  8  to  prove  that  every  behavior  of  this  system  is  serially  correct  for  To- 
The  proof  relies  on  first  establishing  that  the  system’s  behaviors  have  appropriate  return  values 
and  then  showing  that  the  serialization  graph  is  acyclic.  We  show  that  the  system’s  behaviors 
have  appropriate  return  values  by  showing  that  REQUEST-COMMIT  events  for  read  accesses 
are  current  and  safe. 

Lemma  14  Let  S  be  a  generic  system  where  for  each  object  name  X,  Mix  is  used  as 
the  corresponding  generic  object  automaton.  Let  (3  be  a  finite  behavior  of  S.  If  tt  is  a 
REQUEST-COMMIT(T,v)  event  that  occurs  in  visible(/3,  To)  where  T  is  a  read  access  to  X, 
then  tt  is  current  and  safe  in  serial((3). 

Proof:  Let  (3 '  be  the  prefix  of  (3  preceding  tt  and  let  (3"  =  (3'\M\x-  The  preconditions  of  tt 
and  Lemma  13  imply  that  v  =  final-valuc{~i ,  S x)  where  7  is  the  subsequence  of  (3 "  consisting 
of  events  whose  transaction  is  lock-visible  to  T  in  (3" .  Thus,  to  show  that  tt  is  current  in  {3,  it 
suffices  to  show  that  write  -  sequence^ ,  X)  =  clean- write- sequence{serial{(3' ),  X). 
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Since  T  is  not  an  orphan  in  /?,  any  transaction  lock-visible  to  T  in  P"  (and  hence  visible 
to  T  in  P)  is  not  an  orphan  in  serial(fi').  Therefore,  write- sequence^ ~f,X)  is  a  subsequence  of 
clean-write-sequence(serial(p'),X).  On  the  other  hand,  consider  any 
REQUEST_COMMIT(T,,u')  event  in  clean- write-scquence(serial(P'),  X).  Then  T1  is  a  write 
access  and  T'  is  not  an  orphan  in  serial(P');  thus  T‘  is  not  a  local  orphan  in  fi"n.  Since 
T'  conflicts  with  T,  Lemma  11  applied  to  P"^  implies  that  T'  is  lock-visible  to  T  in  p" ix 
and  hence  in  P".  Therefore,  REQUEST-COMMIT^',?/)  occurs  in  write- sequence)^ ,  Sx)- 
Thus,  clean- write- sequence(ser ial{fi' ),  Sx)  is  a  subsequence  of  write- sequence^ ,  S x),  so  in 
fact  clean-write-sequence(serial(P'),  Sx)  =  write- sequence^ ,  Sx)-  Therefore,  7 r  is  current  in 
serial(P). 

If  clean- last- write(serial(fi'),  Sx)  is  defined,  then  Lemma  11  applied  to  fi"ir  implies  that 
clean-last-write(serial(P'),  Sx)  is  lock- visible  to  T  in  P"w.  Therefore,  it  is  visible  to  T  in 
serial(P').  It  follows  that  t  is  safe  in  serial(P).  □ 

Proposition  15  LetS  be  a  generic  system  where  for  each  object  name  X,  Mix  Is  used  as  the 
corresponding  generic  object  automaton.  Let  P  be  a  finite  behavior  of  S.  Then  serial(P)  has 
appropriate  return  values. 

Proof:  We  claim  the  following: 

1.  If  7r  is  a  REQUEST_COMMIT(T,v)  event  occurring  in  visible(P,To),  and  T  is  a  write 
access  to  X,  then  v  =  OK. 

2.  If  7r  is  a  REQUEST_COMMIT(T,u)  event  occurring  in  visible(P,T0),  and  T  is  a  read 
access  to  X,  then  ir  is  current  and  safe  in  serial(P). 

The  first  of  these  is  immediate,  since  in  the  transition  relation  for  each  object  Mlx,v~  OK 
is  a  precondition  on  each  REQUEST_COMMIT(T,u)  action  where  T  is  a  write  access  to  X. 
The  second  follows  from  Lemma  14.  Then  the  conclusion  follows  from  Lemma  6.  □ 

The  following  proposition  shows  that  Mix  ensures  that  the  serialization  graph  is  acyclic. 
The  serialization  graph  consists  of  two  parts,  conflict(serial)P))  and  precedes(serial(P)).  The 
proof  shows  that  each  of  these  is  consistent  with  the  completion  order;  i.e.,  that  if  (U,U')  G 
conflict(serial(P)),  the  U  completes  before  U1  (and  similarly  for  precedes). 

Proposition  16  LetS  be  a  generic  system  where  for  each  object  name  X,  Mix  Is  used  as  the 
corresponding  generic  object  automaton.  Let  P  be  a  finite  behavior  of  S.  Then  SG{serial(P)) 
is  acyclic. 

Proof:  Let  T  be  visible  to  To  in  p.  We  will  prove  that  SG(serial(P),T)  is  acyclic  by  show¬ 
ing  that  both  conflict(serial(fi))  and  precedes(serial(P ))  are  subrelations  of  the  partial  order 
completion(P),  where  (U,U’)  G  completion(P)  if  U  and  V  are  siblings  such  that  either  P  con¬ 
tains  a  completion  event  for  U  preceding  a  completion  event  for  U'  or  P  contains  a  completion 
event  for  U  and  no  completion  event  for  U'. 

Suppose  (T,  T')  G  precedes(serial(P)).  Then  a  report  event  for  T  and  a 
REQUEST_CREATE(T')  occur  in  serial(P),  in  that  order.  But  there  must  be  a  completion 
event  for  T  preceding  the  report  event;  moreover,  any  completion  event  for  T'  must  follow  the 
REQUEST.CREATE(T').  It  follows  that  (T,T')  €  compleiion(P). 

Now  suppose  that  ( T,T ')  G  conflict(serial(p)).  Then  there  are  events  <f>  and  <f>'  in 
visible(P,To)  such  that  <fi  =  REQUEST_COMMIT(I/,e)  where  V  is  a  descendant  of  T, 
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ft  =  REQUEST.COMMn^f/'jt/)  where  U'  is  a  descendant  of  T',  U  conflicts  with  U‘  and  <j> 
precedes  ft  in  visible{0  ,Tq)  .  Since  U  and  U'  conflict,  there  is  some  object  name  X  such  that 
U  and  U'  are  both  accesses  to  X .  Then  j3\Mlx  is  a  generic  object  well-formed  behavior  of 
Mix  that  contains  both  <j>  and  ft.  Since  U  =  transaction {ft)  is  visible  to  To  in  0  we  know 
that  U  is  not  a  local  orphan  in  0\M\x .  Lemma  11  implies  that  U  is  lock-visible  to  U'  in 
the  prefix  of  0\Mlx  preceding  <f>'.  Since  lca{U,U')  =  parent{T),  we  see  that  (3  contains  an 
INFORM_COMMIT_AT(X  )OF(T)  event  preceding  ft,  and  thus  (since  f3  is  a  generic  behavior) 
that  a  COMMIT(T)  event  occurs  in  0  preceding  ft.  On  the  other  hand,  U'  is  live  in  the  prefix 
of  /3  ending  in  ft,  and  U'  is  not  an  orphan  in  0  (since  REQUEST.COMMIT(t/,,u')  occurs  in 
visible((3,To)).  Thus  T'  is  live  in  the  prefix  of  /3  ending  in  ft  so  any  completion  event  for  T'  in 
(3  must  follow  ft  and  thus  follow  the  completion  event  for  T.  That  is,  ( T,T ')  £  completion {0). 

□ 

Now  we  can  prove  the  main  correctness  theorem  for  Moss’  algorithm. 

Theorem  17  Let  S  be  a  generic  system  where  for  each  object  name  X,  Mix  IS  used  as  the 
corresponding  generic  object  automaton.  Let  (3  be  a  finite  behavior  of  S.  Then  0  is  serially 
correct  for  To- 

Proof:  Proposition  15  implies  that  serial{0 )  has  appropriate  return  values.  Proposition  16 
implies  that  the  graph  SG(serial{0 ))  is  acyclic.  Then  Theorem  8  implies  that  0  is  serially 
correct  for  To.  □ 

6  Extension  to  General  Data  Types 

In  this  section  we  extend  some  of  the  previous  results  to  arbitrary  data  types.  Thus,  we  allow 
serial  objects  to  have  arbitrary  operations,  rather  than  restricting  them  to  be  read/write  objects. 

6.1  Serialization  Graphs 

In  order  to  define  a  serialization  graph  analogously  to  our  previous  definitions,  we  must  know 
how  to  define  “conflict  edges,”  which  in  turn  requires  a  definition  of  conflicts  between  operations 
of  an  arbitrary  data  type.  In  order  to  define  conflicts,  we  use  two  auxiliary  definitions,  of 
“equieffectiveness”  and  “commutativity.” 

Informally,  we  say  that  two  finite  sequences  of  external  actions  of  a  particular  serial  object 
automaton  Sx  are  “equieffective”  if  they  can  leave  Sx  in  states  that  cannot  be  distinguished 
by  any  environment  in  which  Sx  can  appear.  Formally,  we  express  this  indistinguishability  by 
requiring  that  Sx  can  exhibit  the  same  behaviors  as  continuations  of  the  two  given  sequences. 
Let  0  and  0'  be  finite  sequences  of  actions  in  ext(Sx)-  Then  0  is  equieffective  to  0'  if  for 
every  sequence  7  of  actions  in  ext(Sx)  such  that  both  01  and  0ft  are  serial  object  well-formed, 
01  G  finbehs(Sx)  if  and  only  if  0'i  £  finbehs(Sx).9  Obviously,  equieffectiveness  is  a  symmetric 
relation,  so  that  if  0  is  equieffective  to  0'  we  often  say  that  0  and  0'  are  equieffective.  Note 
that  if  0  and  0'  are  serial  object  well-formed  sequences  and  0  is  equieffective  to  0' ,  then  if  0  is 
in  finbehs(Sx),  0'  must  also  be  in  finbehs(Sx)- 

A  special  case  of  equieffectiveness  occurs  when  the  final  states  of  two  finite  executions  are 
identical.  The  classical  notion  of  serializability  uses  this  special  case,  in  requiring  concurrent 
executions  to  leave  the  database  in  the  same  state  as  some  serial  execution  of  the  same  trans¬ 
actions.  However,  this  special  case  is  more  restrictive  than  necessary. 

9This  definition  first  appeared  in  [5]. 
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We  next  define  a  notion  of  “commutativity”  of  operations.10  Let  Sx  be  a  serial  object 
for  object  name  X ,  and  let  (T,  v)  and  (T\  v')  be  operations,  where  T  and  T'  are  accesses 
to  X.  Then  we  say  that  (T,v)  and  (T' ,v')  commute  backwards  provided  that  for  all  finite 
sequences  of  operations  f  the  following  holds.  If  perform(^(T,v)(T',v'))  is  a  finite  behavior  of 
Sx  and  both  perform(£(T,v)(T',v'))  and  perform(£,(T' ,v')(T,v))  are  serial  object  well-formed 
then  perform(^(T' ,v'){T,v))  is  equieffective  to  perforrn(£(T,v)(T',v'))  (and  hence  is  also  a 
behavior  of  Sx)-  Note  that  backward  commutativity  is  a  symmetric  relation. 

We  say  that  two  operations  ( T ,  v )  and  (T',  v ')  conflict  provided  that  they  fail  to  commute 
backwards.  We  say  that  two  accesses  T  and  T'  conflict  provided  that  there  exist  v  and  v'  such 
that  (T,  v )  and  ( T\  v ')  conflict.  We  note  that  the  new  definition  of  “conflicts”  generalizes  the 
definition  given  earlier  for  accesses  to  a  read/ write  object  (where  two  accesses  conflict  unless 
both  are  read  accesses). 

The  following  proposition  generalizes  Proposition  7,  which  considered  only  read/write  ob¬ 
jects. 

Proposition  18  Suppose  that  £  is  a  sequence  of  operations  of  X  such  that  perform (£)  is  a 
serial  object  well-formed  behavior  of  Sx-  Suppose  that  q  is  a  reordering  of  £  such  that  all  pairs 
of  conflicting  operations  occur  in  the  same  order  in  tj  and  in  £.  Then  perform (77)  is  a  behavior 

ofSx. 

Given  the  generalized  notion  of  conflict  relation  defined  above  and  the  same  notion  of 
precedes  used  earlier,  we  define  serialization  graphs  exactly  as  before.  However,  we  cannot  use 
the  same  definition  of  appropriate  return  values,  since  it  relies  on  the  properties  of  read/write 
objects.  We  generalize  it  as  follows.  If  /3  is  a  simple  behavior,  we  say  that  3  has  appropriate 
return  values  provided  that  for  all  object  names  X ,  the  following  is  true:  perform{operations( 7)) 
is  a  behavior  of  5x,  where  7  =  visible{3i  To)\X .  Notice  that  Lemma  5  shows  that  this  is  indeed 
a  generalization  of  the  more  concrete  definition  given  for  systems  where  every  serial  object  is  a 
read/ write  object. 

Now  we  can  show  our  main  theorem  for  arbitrary  data  types. 

Theorem  19  Let  3  be  a  finite  simple  behavior  that  has  appropriate  return  values.  Suppose 
that  SG(3)  is  acyclic.  Then  3  is  serially  correct  for  To- 

Proof:  The  proof  is  essentially  identical  to  the  earlier  proof  for  the  read/write  case.  □ 

6.2  An  Undo  Logging  Algorithm 

Now  we  use  serialization  graphs  to  give  a  proof  of  correctness  of  a  particular  system,  one  in 
which  a  general  “undo  logging”  algorithm  is  used  everywhere.  This  algorithm  works  for  objects 
of  arbitrary  data  type. 

We  model  a  system  using  the  undo  logging  algorithm  as  a  generic  system  in  which  every 
generic  object  automaton  is  the  “undo  logging  object  automaton”  Ux  described  below.  A 
state  s  of  Ux  consists  of  four  components:  s. created,  s. commit-requested,  s. committed  and 
s. operations.  The  first  three  are  sets  of  transactions,  initially  empty,  and  the  last  is  a  sequence 
(log)  of  operations  of  X  (recording  the  sequence  of  operations  that  have  taken  place,  but  with 
operations  removed  if  they  are  later  found  to  be  aborted),  initially  the  empty  sequence.  The 
steps  of  Ux  are  as  follows: 

10The  definition  of  commutativity  required  here  is  slightly  different  from  the  one  used  in  [4],  These  definitions 
and  a  careful  exploration  of  the  differences  between  them  are  described  in  [16]. 
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CREATE(T),  T  an  access  to  X 
Effect: 

s. created  =  s'. created  U  {T} 

INFORM_COMMIT_AT(A)OF(T),  T  ±  T0 
Effect: 

s. committed  =  s' .committed  U  {T} 

INFORM_ABORT_AT(X)OF(T),  T  ?  T0 
Effect: 

s. operations  = 

s'  .operations  —  {( T ',  v')\T'  is  a  descendant  of  T } 

REQUEST_COMMIT(T,n),  T  an  access  to  X  and  v  a  value 
Precondition: 

T  €  s'  .created  —  s'  .commit-requested 
(T,  v)  commutes  backward  with  all  ( T ',  v')  in 
s'  .operations  such  that  some  U  in 
ancestors(T')  -  ancestors(T)  is  not 
in  s'  .committed. 

perform(s' .operations{T,v))  is  a  behavior  of  S\ 

Effect: 

s. operations  =  s'.operations(T,v) 
s.  commit-requested  =  s'  .commit-requested  U  {T} 

The  algorithm  is  described  very  abstractly;  for  example,  the  “state”  is  kept  simply  as  a  log 
of  operations,  rather  than  in  some  more  compact  form.  Practical  implementations  would  need 
to  compact  the  information  in  the  operations  log,  and  rest^’c  ..ie  nondeterminism  in  choosing 
which  active  invocation  to  respond  to.  Our  results  app*y  a  fortiori  to  implementations  of  the 
algorithm  in  which  the  state  is  compacted,  <  ud  in  which  the  nondeterminism  is  restricted. 

Informally,  the  algorithm  works  as  follows.  When  an  operation  is  executed  (i.e.,  a 
REQUEST_COMMIT  occurs  for  an  access),  tli°  operation  is  appended  to  s. operations.  A 
REQUEST_COMMIT(T,u)  is  allowed  to  occur  only  if  it  commutes  with  all  operations  executed 
by  transactions  that  are  not  visible  to  T.  The  commit  of  a  transaction  is  simply  recorded 
in  s. committed]  this  component  is  used  in  the  precondition  for  REQUEST_COMMIT(T,u) 
to  determine  which  transactions  are  visible  to  T.  When  a  transaction  aborts,  all  operations 
executed  by  its  descendants  are  removed  from  the  log;  this  has  the  effect  of  “undoing”  all  the 
effects  of  the  transaction. 

6.3  Basic  Properties  of  Ux 

Here  we  give  some  properties  of  Ux-  As  before,  these  can  be  proved  by  common  techniques 
such  as  invariant  assertions  or  arguments  about  sequences  of  actions. 

The  statements  of  the  results  below  require  some  terminology  describing  what  can  be  de¬ 
duced  about  the  status  of  transactions  from  the  local  behavior  of  Ux-  Let  (3  be  a  sequence  of 
actions  of  Ux  and  let  T  and  T'  be  transaction  names.  We  define  the  notion  of  a  local  orphan 
as  for  Mix-  we  say  that  T  is  a  local  orphan  at  X  in  (3  if  an  INFORM_ABORT_AT(A")OF(C/) 
event  occurs  in  (3  for  some  ancestor  U  of  T.  We  define  a  slightly  different  notion  of  visibility:  we 
say  that  T  is  locally  visible  at  X  to  T'  in  (3  if  (3  contains  an  INFORM_COMMIT_AT(A)OF((/) 
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event  for  every  U  €  ancestors(T )  -  ancestor s(T').  (Notice  the  difference  with  the  definition  of 
lock-visible,  which  requires  the  INFORM_COMMIT  events  to  occur  in  leaf-to-root  order.)  If  0 
is  a  behavior  of  a  generic  system,  we  note  that  T  is  locally  visible  to  T'  at  X  in  0\Ux  only  if 
T  is  visible  to  V  in  0.  Similarly  T  is  a  local  orphan  at  X  in  0\U x  only  if  T  is  an  orphan  in  0 
The  following  two  lemmas  characterize  the  operations  component  of  the  state  of  Ux- 

Lemma  20  Let  0  be  a  finite  generic  object  well-formed  schedule  of  Ux  that  can  lead  to  state 
s.  Then  s. operations  is  exactly  the  subsequence  of  operations^ )  obtained  by  removing  all  op¬ 
erations  (T,v)  such  that  an  IN  FORM-ABORT.  AT  (X  )0F(U )  for  some  ancestor  U  of  T  occurs 
after  the  REQUEST.COMMIT(T  ,v)  in  0. 

Lemma  21  Let  0  be  a  finite  generic  object  well-formed  schedule  of  Ux  that  can  lead  to  state 
s.  Let  T  be  any  set  of  transaction  names  such  that  T  fl  s. committed  =  0. 

1.  If  (T',v')  precedes  (T",  v")  is  s. operations,  T'  is  a  descendant  of  a  transaction  in  T  and 
T"  is  not,  then  ( T',  v')  commutes  backward  with  (T" ,  v"). 

2.  If  £  is  the  sequence  of  operations  obtained  by  removing  the  descendants  of  all  transactions 
in  T  from  s. operations,  then  perform^ )  is  a  behavior  of  Sx  • 

The  next  lemma  parallels  Lemma  11. 

Lemma  22  Let  0  be  a  generic  object  well-formed  schedule  of  Ux-  Suppose  distinct  events 
it  —REQUEST.COMMIT(T,v)  and  k'  =  R EQ U ES T. C0MMIT(T',v')  occur  in  0,  where  (7» 
and  (T',  v')  conflict.  If  7T  precedes  it'  in  0  then  either  T  is  a  local  orphan  in  0'  or  T  is  locally 
visible  to  T'  in  0' ,  where  0'  is  the  prefix  of  0  preceding  it'. 

6.4  Correctness  Proof 

First,  we  show  that  the  condition  on  appropriate  return  values  is  satisfied. 

Proposition  23  Let  S  be  a  generic  system  where  for  each  object  name  X ,  Ux  is  used  as  the 
corresponding  generic  object  automaton.  Let  0  be  a  finite  behavior  of  S.  Then  serial{0)  has 
appropriate  return  values. 

Proof:  Fix  a  particular  object  name  X.  We  must  show  that 
perform(operations(visible(0 ,T0)\X ))  is  a  behavior  of  Sx-  Let  s  be  the  unique  state  of  Ux  such 
that  0  can  lead  to  s.  We  define  T  to  be  the  set  of  all  transactions  other  than  To  that  are  not 
committed  in  0.  It  follows  that  no  transaction  in  T  can  be  in  s. committed. 

Lemma  20  implies  that  s. operations  is  exactly  the  subsequence  of  operations(0)  obtained  by 
removing  all  operations  (T,  v)  such  that  an  INFORM_ABORT_AT(X)OF(t/)  for  some  ancestor 
U  of  T  occurs  after  the  REQUEST_COM_MIT(T,i>)  in  0.  Let  £  be  the  sequence  of  operations 
that  results  by  removing  descendants  of  transactions  in  T  from  s. operations.  We  claim  that 
opera  tions(visible(0,To)\X)  =  £. 

The  claim  is  proved  as  follows:  Both  sequences  are  subsequences  of  operations(0),  and  so 
common  operations  occur  in  the  same  order.  We  must  show  that  the  same  operations  appear 
in  both  sequences. 

Suppose  that  (T,v)  appears  in  operations{visible{0,To)\X).  Then  no  ABORT (U)  appears 
in  0  for  any  ancestor  U  of  T,  and  hence  no  INFORM_ABORT_AT(A')OF(I/)  appears  in  0. 
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Therefore,  (T,  v)  is  in  s. operations.  Also,  T  cannot  be  a  descendant  of  any  transaction  in  T, 
since  T  is  visible  to  To  in  (3.  Therefore,  (T,  v)  appears  in  £. 

Now  suppose  (T,  v)  appears  in  £.  Then  T  is  not  a  descendant  of  any  transaction  in  T,  so 
that  all  ancestors  of  T  except  for  T0  are  committed  in  (3.  Therefore,  T  is  visible  to  To  in  /3,  and 
so  (T,  v)  appears  in  operations(visible({3,To)\X).  This  establishes  the  claim. 

Now  Lemma  21  implies  that  operations(visible((3  ,To)\X)  is  a  behavior  of  Sx,  as  needed.  □ 
Next,  we  show  that  the  serialization  graphs  are  acyclic;  the  proof  of  this  result  is  quite 
similar  to  that  of  Proposition  16. 

Proposition  24  Let  S  be  a  generic  system  where  for  each  object  name  X ,  Ux  is  used  as  the 
corresponding  generic  object  automaton.  Let  (3  be  a  finite  behavior  of  S.  Then  SG{serial{(3)) 
is  acyclic. 

Proof:  Let  T  be  visible  to  T0  in  f3.  We  will  prove  that  SG(serial((3),T )  is  acyclic  by  show¬ 
ing  that  both  conflict(serial{(3))  and  precedes(serial(/3 ))  are  subrelations  of  the  partial  order 
completion((3).u 

Suppose  (T,T')  €  precedes(serial(/3)).  Then  a  report  event  for  T  and  a 

REQUEST_CREATE(T')  occur  in  serial(/3),  in  that  order.  But  there  must  be  a  completion 
event  for  T  preceding  the  report  event;  moreover,  any  completion  event  for  T'  must  follow  the 
REQUEST_CREATE(T').  It  follows  that  (T,  T')  6  completion(/3). 

Now  suppose  that  (T,T')  €  conflict(serial(fi)).  Then  there  are  events  <f>  and  <f>'  in 
visible(/3,To)  such  that  <j)  =  REQUEST_COMMIT(17,u)  where  U  is  a  descendant  of  T,  <f>'  = 
REQUEST_COMMIT(f/',u')  where  U'  is  a  descendant  of  T',  U  conflicts  with  U'  and  (f>  precedes 
4>'  in  visible((3,To).  Since  U  and  U'  conflict,  there  is  some  object  name  X  such  that  U  and  U' 
are  both  accesses  to  X.  Then  (3\Ux  is  a  generic  object  well-formed  behavior  of  Ux  that  contains 
both  <j)  and  .  Since  U  =  transaction (<f>)  is  visible  to  To  in  f3  we  know  that  U  is  not  a  local 
orphan  in  f3\Ux-  Lemma  22  implies  that  U  is  locally  visible  to  U'  in  the  prefix  of  (3\Ux  preceding 
<t>' .  Since  lcrr(U,  U ')  =  parent(T),  we  see  that  (3  contains  an  INF0RM_C0MMIT_AT(2f)0F(T) 
event  preceding  <f>',  and  thus  (since  (3  is  a  generic  behavior)  that  a  COMMIT(T)  event  occurs 
in  (3  preceding  <f>r.  On  the  other  hand,  U'  is  live  in  the  prefix  of  (3  ending  in  <j>',  and  U'  is  not  an 
orphan  in  /?  (since  REQUEST_COMMIT(^/',^’,)  occurs  in  visible{(3,To)).  Therefore  T'  is  live  in 
the  prefix  of  (3  ending  in  </ V  so  any  completion  event  for  T'  in  (3  must  follow  <f>'  and  thus  follow 
the  completion  event  for  T.  That  is,  (T,  T')  €  completion(fi).  □ 

Theorem  25  Let  S  be  a  generic  system  where  for  each  object  name  X,  Ux  is  used  as  the 
corresponding  generic  object  automaton.  Let  ft  be  a  finite  behavior  of  S.  Then  (3  is  serially 
correct  for  To. 

Proof:  Proposition  23  implies  that  serial((3 )  has  appropriate  return  values.  Proposition  24 
implies  that  the  graph  SG(serial((3 ))  is  acyclic.  Then  Theorem  19  implies  that  (3  is  serially 
correct  for  To-  □ 

7  Conclusions 

In  this  paper  we  have  presented  a  proof  technique  for  nested  transaction  systems.  Using  this 
technique,  two  properties  must  be  demonstrated  to  show  correctness:  the  return  values  for 

11  Recall  that  ( U,U ')  €  completion (0)  if  U  and  U'  are  siblings  such  that  either  (3  contains  a  completion  event 
for  U  preceding  a  completion  event  for  U'  or  else  0  contains  a  completion  event  for  U  and  no  completion  event 
for  {/'. 
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operations  must  be  shown  to  be  “appropriate,”  and  a  “serialization  graph”  must  be  shown 
to  be  acyclic.  The  first  property  corresponds  to  an  assumption  that  is  made  implicitly  in  the 
classical  theory  of  concurrency  control.  The  second  property  generalizes  the  serialization  graphs 
of  the  classical  theory  to  nested  transactions. 

The  classical  theory  has  been  extended  in  a  variety  of  ways,  for  example  to  model  con¬ 
currency  control  and  recovery  algorithms  that  use  multiple  versions,  and  to  model  replication 
algorithms.12  It  should  be  possible  to  develop  techniques  based  on  the  model  presented  in  this 
paper  that  parallel  the  techniques  used  in  the  classical  theory  for  these  other  kinds  of  systems. 
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